«BELL»

Bigliettazione Elettronica Lombardia

«BELL»

Requisiti tecnici delle smartcard (modello dei dati - Card Data Model)

Indice

1. INTRODUZIONE 4

2. DESCRIZIONE DEL DOCUMENTO 4

3. ACRONIMI E CONVENZIONI 5

4. NORMATIVA E DOCUMENTI DI RIFERIMENTO 5

5. DIZIONARIO DEI DATI UTILIZZATI NELLE SMARTCARD A MICROPROCESSORE PER IL SISTEMA BELL 7

5.1. Regole di codifica 7

5.2. Elenco dei dati utilizzati 12

6. DESCRIZIONE DELLE STRUTTURE DATI DI BIGLIETTAZIONE 37

6.1. Struttura dell’ Environment 37

6.2. Struttura relativa al titolare della smart card 38

6.3. STRUTTURA COMUNE “GIORNALE TRASPORTI” E “EVENTI SPECIALI” 39

6.4. STRUTTURA ELENCO DEGLI “EVENTI SPECIALI” 41

6.5. Struttura Elenco dei contratti 41

6.6. Struttura di un Contratto 42

7. REGOLE DI UTILIZZO 62

7.1. Stadi del ciclo di vita 62

7.1.1. Personalizzazione dell’applicazione DOFOCO 62

7.1.1.1. Personalizzazione dell’Environment 62

7.1.1.2. Personalizzazione del titolare della carta 62

7.1.2. Identificazione e autenticazione 62

7.1.3. Distribuzione 63

7.1.4. Validazione 63

7.1.5. Consultazione 63

7.2. Gestione della priorità dei contratti 64

7.2.1. Meccanismo di selezione di un contratto 67

7.2.2. Principio generale di aggiornamento allo stato “cancellabile” di un contratto 68

7.2.3. Esempio di ricerca di un titolo validabile 69

7.3. Regole di sostituzione di un contratto cancellabile 69

7.4. Soppressione di un contratto 69

7.5. Principi generali di sicurezza 70

7.6. Vincoli di sicurezza legati all’utilizzo di un contratto a contatore fisico 71

7.7. Regole di scrittura del file BestContracts 72

7.8. Ricerca di spazio per inserire un contratto 74

7.9. Ricerca di una posizione per inserire un diagnostico 76

8. MAPPA DELLE CARTE ESISTENTI UTILIZZATE DA ATM E TRENORD 78

8.1. LA CARTA DI TRASPORTO 97 STRUTTURA 2 78

8.2. LA CARTA TRASPORTO 97 STRUTTURA 3 80

8.3. La Carta GTM Light 81

8.4. La CT2000 Transcarte 83

8.5. Caratteristiche relative ai supporti previsti 84

8.6. Nomenclatura delle applicazioni Intercode 86

9. SMARTCARD A MICROPROCESSORE PREVISTE PER IL SISTEMA BELL 87

9.1.1. Introduzione 87

9.1.2. Protocolli di comunicazione delle carte a microprocessore 87

9.1.3. Definizione dei requisiti fisici e meccanici delle carte a microprocessore 88

9.1.4. Definizione dei requisiti elettrici delle carte a microprocessore 88

10. CARTE A MEMORIA (CHIP ON PAPER) 89

10.1. REQUISITI TECNICI CARTA A MEMORIA (COP) 89

10.1.1. Introduzione 89

10.1.2. Funzionamento delle carte Mifare Ultra Light 89

10.1.3. Codice seriale carta (serial number) 90

10.1.4. Lock byte 90

10.1.5. OTP byte 91

10.1.6. Requisiti fisici e meccanici 91

10.1.7. Durata della smart card 91

11. APPENDICE A 92

12. APPENDICE B 92

1. Introduzione

Il presente documento intende distribuire le indicazioni dettagliate sulla struttura dati contenuta nelle smart card e nelle carte a memoria per implementare il nuovo sistema di tariffazione “STIR” previsto sul territorio della Regione Lombardia dal progetto BELL.

Tale struttura tiene conto delle linee guida adottate dagli operatori ATM e TRENORD che preve- dono una migrazione verso le smart card con tecnologia Calypso rev. 3.1 mantenendo inalterata la struttura delle carte esistenti.

Gli operatori di trasporto che vogliono partecipare al sistema BELL dovranno utilizzare il presente documento implementando la struttura descritta sulle carte Calypso rev. 3.1.

Per motivi tecnici è opportuno che sia un soggetto unico a gestire i seguenti aspetti:

• Definizione e distribuzione delle nuove carte Calypso rev 3.1;

• Definizione, gestione e distibuzione delle SAM legate al progetto BELL e regole di firma per l’interoperabilità;

• Definizione puntuale dei valori utilizzati per ogni campo della struttura definita in questo do- cumento.

Si ipotizza che tale soggetto possa essere costituito da un consorzio di operatori oppure dal prin- cipale affidatario dei servizi ferroviari regionali.

2. Descrizione del documento

Nel presente documento viene trattata la normativa “Intercode” (normativa francese omologata NF P 99-405) che stabilisce le raccomandazioni di codifica standard dei dati di bigliettazione.

Esso descrive le regole di interoperabilità per la codifica dei dati di bigliettazione utili per stabilire le specifiche tecniche di alto livello per l’adozione delle specifiche funzionali di DOFOCO e di DOFOCO+, e precisamente:

• le strutture e i dati utilizzati (significato, valori permessi), le loro codifiche, il loro carattere obbligatorio o no.

• alcune modalità di gestione del ciclo di vita di questi dati nel corso delle operazioni che coinvolgono il cliente e la sua carta

Ciascun ente committente selezionerà fra le scelte offerte nel documento le funzioni e i codici di cui necessita nel suo contesto tariffario locale tenendo conto del livello di interoperabilità che si vuole raggiungere. La gamma delle scelte offerte vuole essere rappresentativa dell’insieme delle situazioni conosciute ad oggi a livello regionale.

Al momento di un’estensione dell’intermodalità, la compatibilità dell’applicazione sviluppata ini- zialmente nel rispetto delle precedenti edizioni di questo documento con quella sviluppata ulte- riormente utilizzando interamente o in parte la presente edizione deve essere garantita caso per caso tramite complementi informatici da installare nei terminali.

Su di una carta, ciascuna applicazione di bigliettazione non può riferirsi che a una sola versione di Intercode e a una sola istanza. Queste due informazioni sono contenute nel dato EnvApplication- VersionNumber. Il presente documento e la sua precedente edizione così come la norma speri- mentale utilizzano lo stesso numero di versione (2) in questo dato EnvApplicationversionNumber,

a causa della compatibilità che è stata mantenuta. Il documento è costituito da quattro parti:

1) l’elenco delle regole di codifica utilizzate (per tipo di dati) e dei dati stessi; per ciascun dato è indicato il nome, la sua opzionalità (obbligatorio, referenziato o no) all’interno della struttura di dati a cui è collegato, la lunghezza, la definizione e le regole di codifica che gli si applica- no. Abitualmente il nome di un dato è un nome composto costituito dal nome della struttura nella quale si trova, seguito dal nome proprio del dato. Un certo numero di nomi contengono la parola “data” tra le due parti, il che permette di essere conformi alla normativa NF EN 1545 parti 1 e 2, che prevede campi liberi detti “data”. Questi campi corrispondono a dati sia non previsti nella normativa NF EN 1545 parti 1 e 2, sia previsti da altre strutture;

2) l’elenco delle strutture di dati, con i dati che le compongono, Per le strutture di descrizione dei contratti, esistono numerose possibilità per rispondere a diversi contesti funzionali: Quello urbano con tariffazione forfettaria, quello urbano e/o interurbano, e quello ferroviario solo o associato all'urbano/interurbano;

3) lo scheletro generale degli stadi classici del ciclo di vita della carta. Questo scheletro si compone di processi di gestione dei contratti o delle altre strutture di dati (elenchi di contratti, eventi, contatori) che cercano di ottimizzare lo spazio di memoria sulla carta e di ridurre i tempi di trattamento delle operazioni di validazione;

4) regole precise di posizionamento delle diverse strutture di dati (dette anche file logici) su 5 carte con microchip della famiglia detta “Calypso 1” CD97 struttura 2, CD 97 struttura 3, GTML, CT 2000 Valenciennes. Naturalmente tutto questo include la descrizione (nome, di- mensione) dell'applicazione di trasporto e dei file di ciascuna delle sue carte. In pratica, que- sto spazio di memoria è strutturato in applicazioni e file fisici, ciascuno dei quali gestito da un insieme di chiavi, dove lo spazio disponibile è un multiplo di 29 bytes (ovvero di .232 bit).

Le parti da 5 a 7 (inerenti i precedenti punti 1), 2) e 3)) sono indipendenti dal tipo di carta utilizzata, benché i files utilizzati (elenco dei contratti con i loro riassunti o struttura BestContracts, giornale ecc.) definiti siano particolarmente adatti a queste carte.

3. Acronimi e Convenzioni

Vengono usati nel presente documento i seguenti acronimi:

• BELL: Bigliettazione Elettronica Regione Lombardia

• TDVE: Titoli di vendita elettronici

• STIBM: Sistemi tariffari integrati del Bacino di Mobilità

• STIL: Sistema tariffario integrato lineare

• TIR: Tariffa integrata regionale

• STIR: Sistema tariffario integrato regionale

• SV: Borsellino elettronico (stored value)

• COP: Chip on paper

• AO: Autorità Organizzatrice

• CEN: Comitato Europeo di Normalizzazione

• OD: Origine-Destinazione

4. Normativa e documenti di riferimento

I seguenti documenti / normative di riferimento sono indispensabili per l’applicazione del presen- te documento. Per i riferimenti datati, si applica solo l’edizione citata. Per i riferimenti non datati, si applica l’ultima edizione del documento di riferimento (compresi gli eventuali emendamenti).

Specifiche del sistema operativo Calypso revision 3.1 - reperibile sul sito del Calypso Network Association;

• Xxxxx XXX 00000 parti da 1 a 4;

• Norme ISO 7816 parti da 1 a 4 e successive in conformità con quanto definito al punto "2";

• Norme EN 1545 per la definizione del modello dati (per quanto applicabile).

NF EN 1545-1, Sistemi di carte di identificazione – Applicazioni per il trasporto terrestre – Parte 1: Tipi di dati elementari, codifiche generali ed elementi di dati generali (indice di classificazione: Z 15-700-1).

NF EN 1545-2, Sistemi di carte di identificazione – Applicazioni per il trasporto terrestre – Parte 2: Elementi di dati ed elenchi di codici relativi al pagamento del trasporto (indice di classificazio- ne: Z 15-700-2).

ISO/CEI 14443 (tutte le parti), Carte di identificazione - Carte a circuito(i) integrato(i) senza con- tatto – Carte di prossimità.

I requisiti di conformità con il presente documento sono definiti negli Articoli da 5 a 8.

5. Dizionario dei dati utilizzati nelle Smartcard a microprocessore per il sistema BELL

5.1. Regole di codifica

Questo elenco è destinato a descrivere le regole di codifica che vengono utilizzate nel dizionario dei dati. Esse non sono contraddittorie con l’applicazione della normativa NF EN 1545 parti 1 e 2. Quest’ultima autorizza infatti l'utilizzo di altre regole (vedere NF EN 1545-1 paragrafo 9.3.3).

Tipo

Codifica

Codifica “chiave di ricerca contratto”

Codifica dell’Operatore o del gruppo di operatori fornitori del servizio offerto tramite un contratto o gestore del contratto. Contenuto nella struttura BestContracts, esso permette di accelerare l'identificazione degli operatori. Le identificazioni degli operatori di rete sono N. Operatore ‘0’h MULTIMODAL (multimodalità completa sull’insieme della rete) Da ‘1’h a ‘14’h: principali trasportatori o gruppi di trasportatori ‘15’h: gestore di contratto Questi valori dipendono dal bacino di interoperabilità al quale i trasportatori sono collegati.

Tipo	Codifica
Codifica “operatore(i)”	Su 8 bit. Codifica dell’Operatore o del gruppo di operatori fornitori del servizio offerto tramite un contratto. I valori sono subordinati alla rete di accettazione (NetworkId) Questa codifica è utilizzata nella struttura Contratto. E’ subordinata alla Chiave di ricerca Contrat secondo il seguente meccanismo: Valore della chiave di ricerca Valore dell'operatore 0 0 1 1 … 13 13 14 14 15 15..255
Codifica “data”	Codifica su 14 bit il numero di giorni a partire dal 1/1/1997 che vale 0.
Codifica “ora minuto”	Codifica su 11 bit il numero di minuti passati da mezzanotte

Tipo	Codifica
Codifica “Paymethod”	I valori di Paymethod su 11 bit, descritti nella norma NF EN 1545 parti 1 e 2 e utilizzati sono Sigla Valore decimale Valore esadecimale Valore binario Debito PME ‘0128’d ‘80’h ‘0001000 0000’b Specie ‘0144’d ‘90’h ‘0001001 0000’b Assegno mobilità ‘0160’d ‘A0’h ‘0001010 0000’b Carta di pagamento ‘0179’d ‘B3’h ‘0001011 0011’b Assegno ‘0164’d ‘A4’h ‘0001010 0100’b Assegno vacanze ‘0165’d ‘A5’h ‘0001010 0101’b Telepagamento ‘0183’d ‘B7’h ‘0001011 0111’b Teleregolazione ‘0208’d ‘D0’h ‘0001101 0000’b Buono di cassa ‘0215’d ‘D7’h ‘0001101 0111’b Versamento preliminare - idem Buono di scambio - idem Buono di viaggio - idem Buono sconto ‘0217’d ‘D9’h ‘0001101 1001’b
Codifica “importo”	Su 16 bit. Se la divisa non è precisata, gli importi sono espressi in centesimi di euro.
Codifica “terminale”	L’identificazione del terminale utilizzato avviene a seconda dell’operatore in questione.
Codifica “luogo”	L’identificazione di un luogo (stazione, fermata) avviene a seconda dell’operatore in questione.

Tipo	Codifica
Codifica “luogo geografico”	L’identificazione di un luogo (città) avviene per l’insieme degli operatori della rete di interoperabilità Su 5 cifre (17 bit): Il dipartimento (2 cifre) + il codice INSEE della città (3 cifre)
Codifica “NetworkId”	Identificazione dell’AO o del gruppo di AO le cui zone geografiche inglobano l’insieme degli operatori
Codifica “puntatore al contratto”	I contratti sono identificati da un numero (1..15) codificato da ‘00001’b a ‘01111’b ‘00000’b non è significativo I diritti semplici (holderProfile) sono identificati da un numero da ‘10000’b a ‘10011’b

Tipo

Codifica

Codifica “priorità”

Al momento della validazione, la priorità di un biglietto andata e ritorno passa per esempio da 3 a 7 (a meno che il contratto non diventi cancellabile, nel qual caso il valore è F) Priorità Tipi ‘0’h priorità immediata di categoria 8 ‘1’h priorità immediata di categoria 9 ‘2’h priorità immediata di categoria A ‘3’h priorità immediata di categoria B ‘4’h priorità ritorno di categoria 8 ‘5’h priorità ritorno di categoria 9 ‘6’h priorità ritorno di categoria A ‘7’h priorità ritorno di categoria B ‘8’h priorità di default di categoria 8 ‘9’h priorità di default di categoria 9 ‘A’h priorità di default di categoria A ‘B’h priorità di default di categoria B ‘C’h priorità di default di un contratto non validabile (un diritto particolare) ‘D’h Non definito ‘E’h priorità dei contratti non validabili ma non cancellabili (contenenti un valore residuo) ‘F’h priorità dei contratti cancellabili (contratto esaurito x xxxxxxx)

5.2. Elenco dei dati utilizzati

Questo elenco alfabetico costituisce il dizionario propriamente detto. Esso si riferisce all’insieme dei dati utilizzati specificando per ciascuno di essi:

• il nome;

• la lunghezza (colonna Lg);

• il suo stato (colonna St);

• la sua definizione;

• la sua codifica.

Lo stato di una variabile può assumere tre valori:

O: per “obbligatoria”. Lo stato obbligatorio impone all’insieme dei trasportatori di gestire il dato su tutte le carte interoperabili.

R: per “referenziato”. Lo stato referenziato impone all’insieme dei trasportatori che gestiscono questo dato di farlo secondo la definizione presentata. Il suo utilizzo è opzionale.

NR: per “non referenziato”. Lo stato non referenziato indica che la variabile necessita di un ac- cordo locale per essere utilizzata. L’utilizzo eventuale dei dati NR deve comunque rispettare i requisiti di lunghezza enunciati.

L’organizzazione di questi dati in strutture logiche è descritta nella presente paragrafo caratterizza- to dalla tabella seguente.

Nome	St	Lg	Definizione e codifica
BestContractNetworkId	R	24	Per default “EnvNetworkId” Codifica a seconda di “NetworkId”
BestContractPointer	O	5	Specifica il contratto in questione Codifica secondo “indicatore di contratto”
BestContractTariff	O	16	Questo dato si scompone in tre parti: ⎯ 4 bit di identificazione del (o degli) operatore(i), codifica a seconda della “chiave di ricerca contratto” ⎯ 8 bit di identificazione della struttura “PublicTransportContract” o “Contract” e della sottostruttura “data” utilizzata (valore della struttura) ⎯ 4 bit di priorità assoluta del contratto descritto (codifica secondo “priorità”), la priorità tra i contratti così come la priorità assoluta è data dalla loro posizione relativa nell’elenco “BestContracts”
BestContracts	O	4	Numero di contratti contenuti nell’elenco (0..15) il valore massimo dipende dalla carta Questo numero corrisponde al numero di contratti effettivamente presenti per l’applicazione
ContractAuthenticator	O	16	Sigla del contratto
ContractCustomerNumber	NR	32	Numero cliente
ContractCustomerProfile	R	6	Profilo del cliente
ContractDataActivationBitmap	R	8	Insieme di bit. Ogni bit rappresenta un’unità di durata di attivazione. Permette di prorogare la data di attivazione di un inter- vallo pari alla durata dell’attivazione.
ContractDataAmount	R	16	Questo campo indica l’importo ricevuto, sia dall’AO (contractDataType=’3’h) sia dall’abbonato (contractDataType=’4’h) Codifica secondo “importo”
ContractDataAutoloadDateStart	R	14	Data di inizio dell’autoload Codifica secondo “data”
XxxxxxxxXxxxXxxxxxxxXxxxXxxx	X	00	Data di fine dell’autoload Codifica secondo “data”
ContractDataChrono	R	16	Numero cronologico dell’operazione numerata a partire da 1
ContractDataDebitSoldX	R	5	Valore dell’ultimo addebito in viaggi o unità
ContractDataDebitTPurse	R	16	Valore dell’ultimo debito portamonete di trasporto

Nome	St	Lg	Definizione e codifica
ContractDataEndInhibitionDate	R	14	Data di fine sospensione del contratto Codifica secondo “data”
ContractDataEndPeriod	R	14	Data di fine periodo
ContractDataException	R	2	Indica che il venditore ha inserito manualmente il prezzo del contratto Valori subordinati al dato “ContractProvider”
ContractDataFlag	R	2	Flag di telemodifica
ContractDataGeoZone1	R	6	Numero della prima zona autorizzata in collegamento con il back office
ContractDataGeoZone2	R	6	Numero della seconda zona autorizzata in collegamento con il back office
ContractDataGeoZone3	R	6	Numero della terza zona autorizzata in collegamento con il back office
ContractDataGreyList	R	14	Data di trattamento nella lista grigia
ContractDataInhibition	R	1	Indica se il contratto è provvisoriamente sospeso
ContractDataIntermodal	R	4	Gestione dell’intermodalità (interurbana – urbana)
ContractDataJourneyDestination	R	16	Identifica il luogo dove termina il viaggio Valori subordinati al dato “ContractProvider. Codifica se- condo “luogo”
XxxxxxxxXxxxXxxxxxxXxxxxxxxxxx0	X	00	Utilizzato nel caso in cui sia possibile una seconda O/D
ContractDataJourneyDestination_1	R	14	Codice di fermata di destinazione in collegamento con il back office
ContractDataJourneyDestination_2	R	14	Codice di fermata di destinazione in collegamento con il back office
ContractDataJourneyDestination_3	R	14	Codice di fermata di destinazione in collegamento con il back office
ContractDataJourneyDistance	R	16	Distanza permessa tra l’origine e la destinazione Valori subordinati al dato “ContractProvider”
ContractDataJourneyLine1	R	14	Codice linea 1 in collegamento con il back office
ContractDataJourneyLine2	R	14	Codice linea 2 in collegamento con il back office

Nome	St	Lg	Definizione e codifica
ContractDataJourneyOrigin	R	16	Identifica il luogo di inizio del viaggio Valori subordinati al dato “ContractProvider e Codifica secondo “luogo”
ContractDataJourneyOrigin2	R	16	Utilizzato nel caso in cui sia possibile una seconda O/D
ContractDataJourneyOrigin_1	R	14	Codice di fermata di origine in collegamento con il back office
ContractDataJourneyOrigin_2	R	14	Codice di fermata di origine in collegamento con il back office
ContractDataJourneyOrigin_3	R	14	Codice di fermata di origine in collegamento con il back office
ContractDataJourneyRouteNumbers	R	50	Linee autorizzate (0: campo non significativo). 5 linee (codifica di una linea su 10 bit)
ContractDataJourneyRouteVariants	R	8	1 troncone autorizzato (0 = campo non significativo)
ContractDataJourneyVia	R	16	Identifica un tragitto se sono possibili tragitti diversi. Valori subordinati al dato “ContractProvider” Codifica secondo “luogo”
ContractDataJourneyVia1	R	16	Utilizzato quando sono possibili 2 O/D
ContractDataJourneyVia2	R	16	Utilizzato nel caso in cui sia possibile una seconda O/D
ContractDataLimitDate	R	14	Questo campo indica la data limite per la prima validazione. Questo campo è utilizzato per i contratti a validazione fluttuante Codifica secondo “data”
XxxxxxxxXxxxXxxxxxxxxxxxxx	X	0	Specifica il contratto associato che viene utilizzato Codifica secondo “puntatore al contratto”
ContractDataNumber	R	47	Numero di dossier se il contratto beneficia di un incasso Ad esempio questo numero comprende 9 caratteri alfanumerici codificati in base 36
ContractDataPassengerTotal	R	8	Numero di persone del gruppo. Valore non specificato dalla la normativa NF EN 1545 parti 1 e 2
ContractDataPassengerTotal2	R	6	Numero di persone del gruppo. Valore non specificato dalla normativa NF EN 1545 parti 1 e 2
ContractDataPassengerTotal3	R	4	Numero di persone del gruppo. Valore non specificato dalla normativa NF EN 1545 parti 1 e 2
ContractDataPayMethod	R	11	Definisce il mezzo di pagamento utilizzato Codifica secondo “Paymethod”

Nome	St	Lg	Definizione e codifica
ContractDataPriceAmount	R	16	Rappresenta il prezzo del contratto Codifica secondo “importo”
ContractDataProxy	R	20	Questo campo è un numero di 6 cifre che identifica l’AO che prende in carico una parte o l’intero importo di un contratto. Valori subordinati al dato “ContractProvider”
ContractDataProxyReversion	R	2	Indica se l’incasso comprende la prestazione urbana: ⎯ ‘00’b non precisato ⎯ ‘01’b prestazione urbana all’origine incassata ⎯ ‘10’b prestazione urbana alla destinazione incassata ⎯ ‘11’b prestazione urbana all’origine e alla destinazione incassata
ContractDataRate	R	7	Questo campo è un numero che specifica la tassa sull’incasso da parte dell’AO indicato in ContractDataProxy. Questa tas- sa è espressa in percentuale e varia da 0% a 100%.
ContractDataReceiptDelivered	R	1	Specifica se è stato rilasciato un giustificativo. 0 : no, 1: sì
ContractDataReferenceEndActivationDate	R	14	Prima data limite di validità
ContractDataReloadDate	R	14	Data di ricarica del contratto
ContractDataRestrictHebdo	R	14	Restrizioni settimanali: per mezza giornata (2 bit per giorno)
ContractDataRightsCounter	R	8	Saldo del conto di diritti di acquisizione
ContractDataSaleAgent	R	8	Identificativo dell’operatore che ha caricato il contratto Codifica secondo “operatore(i)”
XxxxxxxxXxxxXxxxXxxx	X	00	Data di vendita (carica) del contratto
ContractDataSaleDevice	R	16	Identificazione del terminale utilizzato per caricare il contratto Valori subordinati al dato “ContractProvider”
ContractDataSaleSecureDevice	R	32	Identificazione del SAM utilizzato per caricare il contratto
ContractDataSaleTime	R	11	Ora e minuto di vendita (carica) del contratto
ContractDataScreen	R	8	Presente sui contratti che possono essere visualizzati sul video del portatile passivo. Valori subordinati al dato “ContractProvider”

Nomee	St	Lg	Definizione e codifica
ContractDataSoldPeriod	R	6	Saldo del viaggio nel periodo
ContractDataSoldX	R	8	Saldo dei viaggi o unità Questo campo è associato all’utilizzo di un contatore protetto (vedere 7.6).
ContractDataSoldZones	R	6	Numero di sezioni restanti (contatore)
ContractDataTimetable	R	4	N. del calendario
ContractDataToken	R	4	Gettone corrispondente a un biglietto semplice
ContractDataTokenNumber1	R	16	Numero di coupon in collegamento con il back office
ContractDataTokenNumber2	R	16	Numero di coupon in collegamento con il back office
ContractDataTPurse	R	19	Importo del portamonete trasporto
ContractDataType	R	4	Questo campo permette di indicare il tipo di incasso da parte dell’AO, indicato nel ContractDataProxy: ⎯ ‘1’h: incasso totale dall’AO ⎯ ‘2’h: percentuale del costo totale incassato dall’AO, indicata in ContractDataRate ⎯ ‘3’h: Importo mensile incassato dall’AO, indicato in ContractDataAmount ⎯ ‘4’h: importo mensile incassato dall’abbonato, indicato in ContractDataAmount
ContractDataUsed	R	1	Specifica se il contratto è già stato validato una volta
ContractDataValidityDuration	R	8	Durata di validità del contratto Valori subordinati al dato “ContractProvider”
ContractDataValidityEndDate	R	14	Data di fine validità del contratto
ContractDataValidityEndTime	R	11	Ora di fine validità del contratto
ContractDataValidityJourneys	R	16	Presente se il contratto è utilizzabile solo un numero limitato di volte. Se questo campo è assente, il contratto è utilizzabile liberamente fino al termine della sua validità. Questo campo è associato all’utilizzo di un contatore protetto (vedere 7.6).
ContractDataValidityEndDate	R	14	Data di inizio validità Codifica secondo “data”
ContractDataValidityZoneDestination	R	8	Identifica la zona alla quale appartiene la destinazione del viaggio Valori subordinati al dato “ContractProvider”

Nome	St	Lg	Definizione e codifica
ContractDataValidityZoneOrigin	R	8	Identifica la zona alla quale appartiene l’origine del viaggio Valori subordinati al dato “ContractProvider”
ContractDataValidityZone1	R	8	Zona(e) autorizzata(e) – massimo 8
ContractDataValidityZone2	R	8	Zona(e) autorizzata(e) – massimo 8
ContractDataVehicleAllowed	R	4	Indica il tipo di trasporto utilizzato (valori da 0 a 15). I valori sono: ⎯ ‘10’b ⎯ ‘0’h non precisato ⎯ ‘1’h Bus urbano ⎯ ‘2’h Bus interurbano ⎯ ‘3’h Metro ⎯ ‘4’h Tram ⎯ ‘5’h Treno ⎯ ‘6’h ⎯ ‘7’h Treno + Bus
ContractDataZones	R	6	Numero di sezioni autorizzate
ContractJourneyDestination	R	16	Destinazione del viaggio
ContractJourneyDistance	NR	16	Distanza permessa tra l’origine e la destinazione
ContractJourneyInterchanges	R	8	Numero di corrispondenze
ContractJourneyOrigin	R	16	Origine del viaggio
ContractJourneyRouteNumbers	R	16	Numero di linea
ContractJourneyRouteVariants	NR	8	Altra linea possibile per il viaggio
ContractJourneyRun	NR	16
ContractJourneyVia	R	16	Luogo di passaggio di un percorso
ContractLoyaltyPoints	NR	16	Punti fedeltà
ContractNetworkId	R	24	Identificativo della rete

Nome	St	Lg	Definizione e codifica
ContractPassengerClass	R	8	Rappresenta la classe di servizio dei passeggeri e il loro diritto. Valori attribuiti dalla normativa NF EN 1545 parti 1 e2 ⎯ ‘0’h per indicare che sono permesse tutte le classi (normativa non precisata) ⎯ ‘1’h per indicare la prima classe ⎯ ‘2’h per indicare la seconda classe
ContractPassengerTotal	NR	8	Numero totale di passeggeri
ContractPaymentPointer	NR	32
ContractPayMethod	R	11	Mezzo di pagamento Codifica secondo “Paymethod”
ContractPeriodJourneys	R	16	Numero di passeggeri per periodo
ContractPriceAmount	R	16	Importo del contratto
ContractPriceUnit	R	16	Divisa dell’importo associato
ContractProvider	O	8	Identificativo del (o dei) operatore(i) fornitore(i) del servizio di trasporto Codifica secondo “operatore(i)” Il suo valore è subordinato alla rete di accettazione e alla Chiave di Ricerca Contratto.
ContractRestrictCode	R	8	Codice della restrizione (specifico della rete)
ContractRestrictDay	R	8	Giorno della restrizione
ContractRestrictEnd	R	11	Data di fine della restrizione legata al contratto
ContractRestriction (bitmap)	R	7	Restrizione legata al contratto
ContractRestrictLocation	R	16	Luogo della restrizione
ContractRestrictProduct	NR	16
ContractRestrictStart	R	11	Data di inizio della restrizione legata al contratto
ContractRestrictTimeCode	NR	8	Codice dei periodi orari di non validità durante il giorno
ContractSerialNumber	R	32	Numero di serie del contratto Questo numero viene attribuito dal terminale utilizzato secondo le regole stabilite dall’operatore
ContractServices	R	16	Servizi associati

Nome	St	Lg	Definizione e codifica
ContractStatus	O	8	Stato del contratto Vedere i valori della normativa StatusCode Status Code::=INTEGER(0..127) ⎯ mai validato (0): (Contratto valido mai consumato): Questo valore significa che il contratto non è mai stato utilizzato. Il contratto può essere accettato alla validazione, al controllo o eventualmente esse- re rimborsato secondo le regole di post-vendita del prodotto. Questo stato è impo- stato al momento della distribuzione del prodotto ⎯ Usato una volta (1): (Contratto valido parzialmente consumato): questo valore significa che il contratto è stato utilizza- to almeno una volta. Il contratto può essere accettato alla validazione, al controllo o eventualmente essere rimborsato. Questo stato viene impostato al momento della prima validazione del contratto ⎯ validato (2): ⎯ Contratto già rinnovato (3): (informazione di rinnovo da effettuare già inviata al cliente). Questo stato evita di generare ulteriormente il diagnostico o il messaggio corrispondente all'informazione di rin- novo da effettuare ⎯ perforato (4): ⎯ cancellato (5): ⎯ interrotto (6): ⎯ ok (7): ⎯ Riservato per l’uso CEN (8..12) ⎯ Non disponibile per la validazione (13). (Contratto non validabile). Se lo stato del contratto è 13 (‘0D’h) questo significa che il contratto non è validabile. E’ il caso dei diritti tariffari e dei titoli di viaggio non più validabili ma che conservano un valore residuo ⎯ Libero (può essere riutilizzato) (14) ⎯ Attivo (15): ⎯ Preallocato (non ancora usato) (16) ⎯ Completato, può essere rimosso (17) ⎯ Completato, non può essere rimosso (18) ⎯ Bloccato (19):

Nome	St	Lg	Definizione e codifica
ContractStatus (seguito)			⎯ Gruppo di dati flag criptati (20) (per mantenere la confidenzialità dei dati dell'operatore) ⎯ Gruppo di dati flag anonimi (21) (per gestire le necessità di anonomato) ⎯ Riservato per l’uso CEN (22..32) ⎯ in attesa(33): (Contratto in attesa) questo valore significa che il contratto è in attesa di un trattamento particolare. La gestione di questo stato deve essere precisata ⎯ Riservato per l’uso CEN (34..62) ⎯ sospeso (63): (Contratto sospeso): questo valore significa che il contratto è sospeso. Il contratto non può essere ac- cettato per validazione e controllo. Questo stato può essere impostato per rendere un contratto temporaneamente inutilizzabile (attesa di regolarizzazione di una mensilità per la carta integrale STIF, ad esempio) ⎯ riservato per l’uso CEN (64..87) ⎯ disabilitato (88): (Contratto non valido): questo valore significa che il contratto è inutilizzabile. ⎯ Uso specifico della rete o del provider (89..124) ⎯ contratto sospeso (125) ⎯ contratto non valido (126) ⎯ contratto non valido e rimborsato (127): questo valore significa che il contratto è stato oggetto di una post-vendita. Si trova in uno stato annullato. Il contratto non può più essere accettato per la vali- dazione, il controllo o il rimborso. ⎯ Cancellabile (255): Questo valore significa che il contratto è inutilizzabile e cancellabile. Il contratto non può più essere accettato per la validazione, il controllo o il rimborso. Questo stato viene impostato per evitare che manipolazioni fraudolente possano rendere di nuovo utilizzabile un contratto esaurito
ContractTariff	O	16	Identificazione della tariffa Subordinato a “ContractProvider” Ad esempio in base ad un determinato “ContractProvider” si puo avere: ⎯ i 9 bit più significativi corrispondono al Codice Tariffa del contratto (2 caratteri) ⎯ i 7 bit meno significativi corrispondono al Codice Riduzione (da 0 a 99). Il provider si riserva l'utilizzo dei valori compre- si tra '0000'h e 'BFFF'h
ContractValidityDuration	R	8	Durata di validità del contratto

Nome	St	Lg	Definizione e codifica
ContractValidityEndDate	R	14	Data di fine validità del contratto Codifica secondo “data”
ContractValidityEndTime	R	11	Ora di fine validità del contratto
ContractValidityInfo (bitmap)	R	9	Informazione sulla validità del contratto
ContractValidityJourneys	R	16	Numero di viaggi Questo campo è associato all’utilizzo di un contatore protetto (vedere 7.6).
ContractValidityLimitDate	R	14	Data limite di validità del contratto
ContractValiditySaleAgent	R	8	Agente che ha venduto il titolo
ContractValiditySaleDate	R	14	Data di vendita
ContractValiditySaleDevice	R	16	Apparecchiatura di vendita
ContractValiditySaleTime	R	11	Ora di vendita
ContractValidityStartDate	R	14	Data di inizio validità del contratto Codifica secondo “data”
ContractValidityStartTime	R	11	Ora di inizio validità del contratto
ContractValidityZones	R	8	Se l’uso è limitato a una zona, ogni bit rappresenta una zona coperta (bit 0: Zona 1 e bit 7: Zona 8) (questa codifica è usata anche per tutti i dati nei quali il nome inizia per ContractDataValidityZone)

Nome	St	Lg	Definizione e codifica
ContractVehicleClassAllowed	[6]	6	Classe, dimensione 6 per conformità con la NF EN 1545 parti 1 e 2 0x00: Non specificato 0x01: Prima 0x02: Standard 0x03: Premium VehcielClassCode = INTEGER (0..63) Non specificato (0) prima (1) standard (2) Premium (3) riservata CEN (4..48) specifica del provider (49..63)
EnvApplicationIssuerId	O	8	Identificazione dell’emettitore e creatore dell’applicazione di bigliettazione Permette la codifica di 256 valori Dato subordinato a EnvNetworkId Valori da 0 a 15 unicamente operatori Valori > 15 altro (operatori o AO)
EnvApplicationValidityEndDate	O	14	Data di fine validità dell’applicazione di bigliettazione. E’ generalmente uguale alla data di creazione della carta + durata di vita della carta (3 anni o 4 anni). Questa data deve essere minore o uguale alla data di fine validità della carta. Codifica secondo “data”
EnvApplicationVersionNumber	O	6	Numero di versione dell’applicazione di bigliettazione Questo numero era ‘000xxx’b per la prima edizione (agosto 2002). E’ ‘001xxx’b per l’attuale edizione
EnvAuthenticator	R	16	Vedere NF EN 1545 parti 1 e 2
EnvData2	R	X	Dati supplementari
EnvDataCardStatus	R	1	Tipo di carta

Nome	St	Lg	Definizione e codifica
EnvNetworkId	O	24	Identificazione dell’AO dell’applicazione di bigliettazione Codifica a seconda di “NetworkId”
XxxXxxXxxxxx	XX	00	Metodo di pagamento utilizzato Codifica secondo “Paymethod”
EnvSelectList	NR	32	Vedere NF EN 1545 parti 1 e 2
EventAuthenticator	R/R	16	‘R’ nel quadro di JournalTransport, ‘R’ in caso di un evento speciale Codice di sicurezza
EventCode	O/R	8	‘O’ nel quadro di JournalTransport, ‘R’ in caso di un evento speciale. Il quar- tetto più significativo contiene la modalità di trasporto collegato all’evento. Va- lori attribuiti: ⎯ ‘1’h: bus urbano ⎯ ‘2’h: bus interurbano ⎯ ‘3’h: metro ⎯ ‘4’h: tram ⎯ ‘5’h: treno ⎯ ‘8’h: parcheggio ⎯ altri valori: RUF

Nome	St	Lg	Definizione e codifica
EventCode (seguito)			TransportServiceCode ::= INTEGER { Non specificato (0), Bus urbano (1), Bus interurbano (2), metro (3), tram (4), treno (5), ferry (6), pedaggio (7), parking (8), taxi (9), tunnel (10), ricarica (11), interruzione (12), riparazione (13), (14), altri servizi (15) Il quartetto meno significativo contiene il tipo di transazione collegato all'evento Valori attribuiti: ⎯ ‘1’h: validazione in entrata ⎯ ‘2’h: validazione in uscita ⎯ ‘4’h: controllo volante (a bordo) ⎯ ‘5’h: validazione di prova ⎯ ‘6’h: validazione in coincidenza (entrata) ⎯ ‘7’h: validazione in coincidenza (uscita) ⎯ ‘9’h: annullo della validazione ⎯ ‘D’h : distribuzione ⎯ ‘F’h : invalidazione ⎯ altri valori: RUF

Nome	St	Lg	Definizione e codifica
EventCode (seguito)			PayServicePointInfo INTEGER { Non specificato (0), entrata (1), uscita (2), passaggio (3), punto di controllo (4), autonomo (5), interscambio (6) }} (NF EN 1545 parti 1 e 2 UserActionCode ::= INTEGER { Non specificato (0), entrata (1), uscita (2), passaggio (3), punto di ispezione (4), autonomo (5), interscambio (6), validazione (7), presenzarilevata (8), riservato per uso CEN (9...11), specifico della rete (12...19), specifico del provider (20...31) } )
	R/R	5	‘R’ per il JournalTransport, ‘R’ per un evento speciale Specifica il contratto interessato dall’evento Codifica secondo “indicatore di contratto”
EventDataDateFirststamp	R/R	14	‘R’ per il JournalTransport e per un evento speciale Data di prima validazione del viaggio Codifica secondo “data”

Nome	St	Lg	Definizione e codifica
EventDataRouteDirection	R/R	2	‘R’ per il JournalTransport e per un evento speciale Precisa la direzione sulla linea Valori attribuiti: ⎯ ‘00’b: Indeterminato ⎯ ‘01’b: andata ⎯ ‘10’b: ritorno ⎯ ‘11’b: circolare JourneyTypeCode ::= ENUMERATED { Nonspecificato (0), singolo (1), ritorno (2), circolare (3) }
EventDataSimulation	R/R	1	‘R’ per il JournalTransport, ‘R’ per un evento speciale Precisa se la validazione è avvenuta Se = 0 in modalità di validazione "normale" Se = 1 in modalità "degradata" (che significa l'assenza dell'indicazione del luogo dell'evento)
EventDataTimeFirststamp	R/R	11	‘R’ per il JournalTransport, ‘R’ per un evento speciale Ora e minuto della prima validazione del viaggio Codifica secondo “ora minuto”
EventDataTrip	R/R	2	‘R’ per il JournalTransport, ‘R’ per un evento speciale Specifica il troncone
EventDateStamp	O/O	14	‘O’ per il JournalTransport, ‘O’ per un evento speciale Data dell’evento Codifica secondo “data”

Nome	St	Lg	Definizione e codifica
EventDestination	R/R	16	‘R’ per il JournalTransport, ‘R’ per un evento speciale Identifica la destinazione (fine del viaggio) Valori subordinati al dato “EventServiceProvider”. Codifica se- condo “luogo”
EventDevice	R/R	16	‘R’ per il JournalTransport, ‘R’ per un evento speciale Identificazione del terminale utilizzato (codifica secondo l’operatore)
EventDisplayData	NR/N R	8	‘NR’ per il JournalTransport, ‘NR’ per un evento speciale Vedere NF EN 1545 parti 1 e 2
EventEmployee	NR/N R	240	‘NR’ per il JournalTransport, ‘NR’ per un evento speciale Vedere NF EN 1545 parti 1 e 2
EventJourneyInterchanges	R/R	8	‘R’ per il JournalTransport, ‘R’ per un evento speciale Indica il numero di coincidenze effettuate dopo la prima validazione in entrata Prende il valore ‘1’h alla prima coincidenza Viene incrementato di ‘1’h ad ogni nuova coincidenza
EventJourneyRun	R/R	16	‘R’ per il JournalTransport, ‘R’ per un evento speciale Identificazione della missione Subordinato al dato ‘EventServiceProvider’
EventJourneyDistance	NR/N R	16	‘NR’ per il JournalTransport, ‘NR’ per un evento speciale Indica la distanza corrispondente al viaggio in questione
XxxxxXxxxxxxxXxxx	XX/X X	0	‘XX’ per il JournalTransport, ‘NR’ per un evento speciale Vedere NF EN 1545 parti 1 e 2

Nome	St	Lg	Definizione e codifica
EventLocationId	R/R	16	‘R’ per il JournalTransport, ‘R’ per un evento speciale Se la transazione avviene a terra allora “EventLocationId” identifica il luogo dove la transazione è stata effettuata In caso contrario vedere “EventVehicleId”. Valori subordinati al dato “EventServiceProvider”. Codifica se- condo “luogo”
EventLocationReference	NR/N R	16	‘NR’ per il JournalTransport, ‘NR’ per un evento speciale Vedere NF EN 1545 parti 1 e 2
EventLocationType	NR/N R	5	‘NR’ per il JournalTransport, ‘NR’ per un evento speciale Vedere NF EN 1545 parti 1 e 2
EventNetworkId	R/R	24	‘R’ per il JournalTransport, ‘R’ per un evento speciale Per default EnvNetworkId Codifica a seconda di “NetworkId”
EventNotokCounter	R/R	8	‘R’ per il JournalTransport, ‘R’ per un evento speciale Contatore di eventi anomali
EventPeriodJourneys	NR/N R	16	‘NR’ per il JournalTransport, ‘NR’ per un evento speciale Indica il numero di viaggi effettuati
EventPriceAmount	R/R	16	‘R’ per il JournalTransport, ‘R’ per un evento speciale Indica l’importo della transazione in caso di una validazione con debito del PME: Codifica secondo “importo”
EventPriceUnit	NR/N R	16	‘NR’ per il JournalTransport, ‘NR’ per un evento speciale Vedere NF EN 1545 parti 1 e 2 (per default vedere codfica “importo”)

Nome	St	Lg	Definizione e codifica
EventResult	R/O	8	‘R’ per il JournalTransport. ‘O’ per un evento speciale Codice risultato Valori attribuiti a seconda del tipo di transazione Esempio di diagnostica (eventi speciali): Diag Codice Significato per una validazione in entrata (EventCode = '1'h o '6'h) ‘00’h Niente (nessun diagnostico) EXS ‘08h’ In entrata, selezione scaduta: è stata effettuata da troppo tempo EQI ‘0D’h In entrata, diritti insufficienti: L’abbonamento non è più utilizzabile qui e ora (esempio: l’AR è stato già ef- fettuato su un AHT) EFP ‘1A’h In entrata di stazione aperta, seconda validazione ignorata (la carta è già stata validata) FFP ‘1B’h In entrata di stazione chiusa, seconda validazione ignorata (la carta è già stata validata) EAA ‘22’h In entrata, abbonamento appena scaduto (il rinnovo è già in vendita) EAG ‘28h’ In entrata, abbonamento geograficamente non valido EMI ‘2E’h In entrata a tariffa unica, riserva di moneta insufficiente CMI ‘2F’h In coincidenza, riserva di moneta insufficiente CMP ‘32’h In coincidenza, un pagamento ha avuto luogo (il diritto in concidenza era accettato) EPA ‘38h’ In entrata su un percorso preselezionato, riserva di denaro quasi terminata (non permette il ritorno) EPI ‘39’h In entrata su un percorso preselezionato, riserva di denaro insufficiente per utilizzare il percorso preselezionato CPI ‘3A’h In corrispondenza, tentativo di utilizzo del percorso preselezionato (perché diritto in coincidenza ac- cettato) ma RdA insufficiente EPG ‘3E’h In entrata, percorso preselezionato geograficamente non valido EIS ‘4A'h In entrata, cambio di tariffa per il viaggio preselezionato ETI ‘4F’h In entrata, carta in blocco ETP ‘51’h In entrata di stazione aperta con debito, seconda validazione ignorata FTP ‘52’h In entrata di stazione chiusa con debito, seconda validazione ignorata CTP ‘53’h In corrispondenza in una stazione a tariffa non unica, obbligo di selezionale (il diritto in coincidenza è stato accettato) ETS ‘55’h In entrata, nessun tragitto è stato selezionato ETZ ‘56’h Messaggio commerciale o personale: consultare un distributore

Nome	St	Lg	Definizione e codifica
EventResult (seguito)			Diag Codice Significato per una validazione in entrata (EventCode = '2'h o '7'h) SXG ‘5D’h In uscita, superamento del percorso selezionato e validato SXV ‘60’h In uscita, percorso selezionato validabile ma non validato ZXV ‘61’h In uscita, percorso selezionato validabile ma non validato RXV ‘62’h In uscita, percorso selezionato validabile ma non validato - recidivo SXV ‘66’h In uscita, percorso selezionato non validabile e non validato SFV ‘83’h In uscita, forfait validabile ma non validato – 1° volta RFV ‘85’h In uscita, forfait validabile ma non validato – recidivo SAG ‘90’h In uscita, abbonamento validato ma non validabile ZAG ‘91h’ In uscita, abbonamento validato ma non validabile RAG ‘92’h In uscita, abbonamento validato ma non validabile SPG ‘B0’h In uscita, percorso preselezionato validato ma non validabile ZPG ‘B1’h In uscita, percorso preselezionato validato ma non validabile RPG ‘B2’h In uscita, percorso preselezionato ma non validabile SIV ‘C3’h In uscita, selezione implicita validabile ma non validata ZIV ‘C4’h In uscita, selezione implicita validabile ma non validata RIV ‘C5’h In uscita, selezione implicita validabile ma non validata SIW ‘C6’h In uscita, selezione implicita non selezionata né validata né validabile STA ‘CC’h In uscita nella stazione di entrata, abbandono del percorso STP ‘CD’h In uscita, titolo validato ma annullato in uscita STO ‘D9’h In uscita, nessuna selezione, nessuna validazione, nessun abbonamento STZ ‘DC’h In uscita, seconda uscita (due validazioni di uscita)

Nome	St	Lg	Definizione e codifica
EventResult (seguito)			Valore specifico per il Giornale dei Trasporti Codice Significato per un annullo di validazione (EventCode = '9'h) ‘00’h l’annullo di validazione è OK ‘07’h l’annullo di validazione è OK con un trasferimento del titolo verso un supporto cartaceo (caso ad eccezione del piano 1) ‘10’h l’annullo di validazione non è possibile Codice Significato per un controllo (EventCode = ‘4’h) ‘00’h il controllo è OK Codice Significato per una invalidazione (EventCode = ‘F’h) ‘00’h l’invalidazione è dovuta a “dichiarazione di smarrimento o furto da parte del cliente” ‘07’h l’invalidazione è dovuta a ‘malfunzionamento della carta’ ‘08’h l’invalidazione è dovuta a ‘trasporto fraudolento’ ‘09’h l’invalidazione è dovuta a ‘trasporto monetario fraudolento’
EventRouteNumber	R/R	16	‘R’ per il JournalTransport, ‘R’ per un evento speciale Identificazione della linea Subordinato al dato ‘EventServiceProvider’
EventRouteVariant	NR/N R	8	‘NR’ per il JournalTransport, ‘NR’ per un evento speciale Identificazione di una variante della linea Subordinato al dato ‘EventServiceProvider’
EventSerialNumber	R/R	24	‘R’ per il JournalTransport, ‘R’ per un evento speciale
EventServiceProvider	O/O	8	‘O’ per il JournalTransport, ‘O’ per un evento speciale Operatore responsabile del servizio Codifica secondo ‘operatore(i)’

Nome	St	Lg	Definizione e codifica
EventTimeStamp	O/O	11	‘O’ per il JournalTransport, ‘O’ per un evento speciale Ora e minuto dell’evento Codifica secondo “ora minuto”
EventTotalJourneys	NR/N R	16	‘NR’ per il JournalTransport, ‘NR’ per un evento speciale, Indica il numero massimo di viaggi autorizzati
EventVehicleClass	NR/N R	8	‘NR’ per il JournalTransport, ‘NR’ per un evento speciale Vedere NF EN 1545 parti 1 e 2
EventVehicleId	R/R	16	‘R’ per il JournalTransport, ‘R’ per un evento speciale Se la transazione avviene a bordo di un veicolo, allora "EventVehicleId" identifica il luogo dove la transazione è stata effet- tuata Altrimenti vedere “EventLocationId” Valori subordinati al dato “EventServiceProvider”
HolderBirthDate	R	32	Data di nascita BCD AAAAMMJJ Non compilato se la carta è anonima
HolderBirthName	NR	85	Nome di nascita (17 caratteri * 5 bit) Alfa- beto codificato nel seguente modo: Ciascuna lettera (maiuscole non accentate) di nome e cognome è codificata su 5 bit (valori ASCII in hex - '40'h) “A” è codificata ‘01’h “B” è codificata ‘02’h … “Z” è codificata '1A'h S spazio è codificato '1B'h EOF è codificato '00'h
HolderBirthPlace	NR	115	Luogo di nascita (23 caratteri * 5 bit)
HolderCompany	R	32	Identificazione della società alla quale appartiene il titolare Vedere NF EN 1545 parti 1 e 2
HolderCountryAlpha	NR	24	Nazione del titolare Vedere NF EN 1545 parti 1 e 2

Nome	St	Lg	Definizione e codifica
HolderDataAuthenticator	R	16	Sigla di autenticazione
HolderDataCardStatus	O	4	Tipo di carta: (PersonalisationTypeCode) 0x0 anonymous anonima 0x1 identified, --or declarative individuale dichiarativa 0x2 personalised, individuale nominativa 0x3 provider-specific codifica specifica del fornitore
HolderDataCommercialId	R	6	Indica la natura del prodotto carta. Questa informazione permette di conoscere i prodotti e i servizi inseribili nella carta. Il valore ‘0’h non è significativo. Codifica subordinata a EnvNetworkId
HolderDataProfileStartDate1	R	14	Data di inizio validità della posizione 1
HolderDataProfileStartDate2	R	14	Data di inizio validità della posizione 2
HolderDataProfileStartDate3	R	14	Data di inizio validità della posizione 3
HolderDataProfileStartDate4	R	14	Data di inizio validità della posizione 4
HolderDataResidence	NR	17	Domicilio del titolare Codifica secondo “luogo geografico”
HolderDataSaleDevice	NR	16	Apparecchiatura di vendita
HolderDataStudyPlace	R	17	Luogo di studio del titolare Codifica secondo “luogo geografico”
HolderDataTelereglement	R	4	Significa che il telepagamento è autorizzato (bit=1) o non è autorizzato (bit=0). L’utilizzo è limitato a quattro operatori; ⎯ Ad esempio: ‘xxx1’b autorizzato, ‘xxx0’b proibito ⎯ gli altri valori sono subordinati a EnvNetworkId
HolderDataWorkPlace	R	17	Luogo di lavoro del titolare Codifica secondo “luogo geografico”
HolderForename	NR	85	Nome del titolare (17 caratteri * 5 bit)
HolderIdNumber	R	32	Numero di identificazione del titolare Vedere NF EN 1545 parti 1 e 2

Nome	St	Lg	Definizione e codifica
HolderNetworkId	NR	24	Per default EnvNetworkId Codifica a seconda di “NetworkId”
HolderProfileDate	R	14	Data di fine validità della posizione associata Codifica secondo “data”
HolderProfileNumber	R	8
			Identificazione della posizione
			I valori (0..31) sono attributi seguendo la normativa NF EN 1545-1
			I valori (32..127) sono attribuiti per strutture interoperabili
			I valori (128..255) sono disponibili per strutture di portata locale urbane o interurbane o regionali secondo gli accordi locali.
			ProfileCode ::= INTEGER (0 .. 255)
			⎯ unspecified (0),
			⎯ adult (1),
			⎯ child (2),
			⎯ student (3),
			⎯ ………. (4),
			⎯ ………. (5),
			⎯ ………. (6),
			⎯ ………. (7),

Nome	St	Lg	Definizione e codifica
SpecialEventPointer	O	5	Puntatore all’evento ‘00001’b per il primo evento speciale ‘00000’b non è significativo
SpecialEventProvider	O	8	Identificazione dell’operatore che ha scritto l’evento sulla carta Valori subordinati a SpecialEventNetworkId Codifica secondo “operatore(i)”
SpecialEventSeriousness	O	2	Indica il livello di gravità dell’evento speciale Valori attribuiti: ⎯ ‘00’b nessuna gravità ⎯ ‘01’b evento informativo ⎯ ‘10’b warning ⎯ ‘11’b evento relativo a un errore
SpecialEventNumber	O	4	Questo numero corrisponde al numero di Eventi Speciali (anche detti “diagnostici”) effettivamente presenti per l’applicazione (0..15) limitato dalla carta

Per tutti gli altri dati la definizione e la codifica deve avvenire secondo la normativa NF EN 1545 parti 1 e 2

6. Descrizione delle strutture dati di bigliettazione

Le strutture presentate in questo paragrafo sono estratte dalla normativa NF EN 1545 parti 1 e 2. In ciascuna di queste strutture, i campi in grigio rappresentano le variabili da gestire in modo obbligatorio nel quadro dell’interoperabilità.

La struttura di ciascuna delle variabili è mostrata nell’ultima colonna. Tutte le strutture presen- tate sono inserite nella carta.

6.1. Struttura dell’ Environment

Elementi di dati	Posizioni			Bit	Osservazioni e valori	Status
EnvApplicationVersionNumber	[0]			6	Numero di versione dell’applicazione di bigliettazio- ne	Obblig
Bitmap générale	[1]			7	Bitmap	Obblig
EnvNetworkId		[0]		24	Identificazione della rete	Obblig
EnvApplicationIssuerId		[1]		8	Identificazione dell’emettitore e creatore dell’applicazione di bigliettazione	Obblig
EnvApplicationValidityEndDate		[2]		14	Data di fine validità dell’applicazione di bigliettazione	Obblig
EnvPayMethod		[3]		11		NR
EnvAuthenticator		[4]		16		R
EnvSelectList		[5]		32	Bitmap di insieme di parametri multipli	NR
EnvData		[6]		2	Bitmap	R
EnvDataCardStatus			[0]	1	Struttura della carta	R
EnvData2			[1]	X	Dati supplementari	R

EnvApplicationVersionNumber: Si riferisce alla revisione della normativa utilizzata Sui primi 3 bit:

• ‘ 000b ’ : Intercode I o primo documento edito ufficialmente;

• ‘ 001b ’ : Intercode II

Sugli ultimi tre bit:

• versione dell’istanza utilizzata sulla rete.

EnvNetworkId: Identifica la rete di accettazione (AO o gruppo di AO). La codifica attuale per- mette di identificare solo 1000 valori.

6.2. Struttura relativa al titolare della smart card

Elementi di dati	Posizioni			Bits	Osservazioni e valori	Status
Bitmap generale				8	Bitmap	Obblig
HolderName	[0]			2	Bitmap	Non rif
HolderSurname		[0]		85	Nome del titolare	Non rif
HolderForename		[1]		85	Nome di battesimo del titolare	Non rif
HolderBirth	[1]			2	Bitmap	Rif
HolderBirthDate		[0]		32	Data di nascita	Rif
HolderBirthPlace		[1]		115	Luogo di nascita (23 caratteri * 5 bit)	Non rif
HolderBirthName	[2]			85	Cognome del titolare (17 caratteri)	Non rif
HolderIdNumber	[3]			32	Identifica il titolare	Rif
HolderCountryAlpha	[4]			24	Nazione del titolare	Non rif
HolderCompany	[5]			32	Società del titolare	Rif
HolderProfiles(0..4)	[6]			4	Numero di posizioni (massimo 4)	Rif
HolderProfileBitmap		[0]		3	Bitmap	Rif
HolderNetworkId			[0]	24	Rete	Rif
HolderProfileNumber			[1]	8	Numero di posizione	Rif
HolderProfileDate			[2]	14	Data di fine validità della posizione	Rif
HolderProfileBitmap		[1]		3	Bitmap	Rif
HolderNetworkId			[0]	24	Rete	Rif
HolderProfileNumber			[1]	8	Numero di posizione	Rif
HolderProfileDate			[2]	14	Data di fine validità della posizione	Rif
HolderProfileBitmap		[2]		3	Bitmap	Rif
HolderNetworkId			[0]	24	Rete	Rif
HolderProfileNumber			[1]	8	Numero di posizione	Rif
HolderProfileDate			[2]	14	Data di fine validità della posizione	Rif
HolderProfileBitmap		[3]		3	Bitmap	Rif
HolderNetworkId			[0]	24	Rete	Rif
HolderProfileNumber			[1]	8	Numero di posizione	Rif
HolderProfileDate			[2]	14	Data di fine validità della posizione	Rif
HolderData	[7]			12	Bitmap	Rif
HolderDataCardStatus		[0]		4	Tipo di carta:	Obblig
HolderDataTelereglement		[1]		4	Telepagamento	Rif
HolderDataResidence		[2]		17	Città di residenza	Non rif
HolderDataCommercialId		[3]		6	Prodotto carta	Rif
HolderDataWorkPlace		[4]		17	Luogo di lavoro	Rif
HolderDataStudyPlace		[5]		17	Luogo di studio	Rif
HolderDataSaleDevice		[6]		16	N. logico di XXX	Non rif
HolderDataAuthenticator		[7]		16	Firma	Rif
HolderDataProfileStartDate1		[8]		14	Data di inizio validità della posizione	Rif
HolderDataProfileStartDate2		[9]		14	Data di inizio validità della posizione	Rif
HolderDataProfileStartDate3		[10]		14	Data di inizio validità della posizione	Rif
HolderDataProfileStartDate4		(11]		14	Data di inizio validità della posizione	Rif

Di seguito le definizioni concordate:

• Posizione: Caratteristiche intrinseche di un'entità (persona o società) a un determinato momento. Queste caratteristiche possono, da sole o associate con altre caratteristiche, consentire di beneficiare di un diritto tariffario. Ad esempio una posizione di un cliente è la sua età, che può consentirgli di beneficiare di un diritto tariffario “12-25 anni” di un operatore.

• Diritto tariffario: Diritto personale accordato da uno o più operatori, uno o più AO o ser- vizi comuni a un cliente che documenta una determinata posizione. Questo diritto per- sonale permette di determinare la tariffa applicabile e il contributo dei diversi finanziatori del sistema di trasporto.

• Un diritto semplice deve essere memorizzato nella zona titolare (HolderProfiles). In ca- so di complessità, si deve utilizzare la struttura contratto.

• Non si codificherà mai lo stesso contratto sia nella zona profilo del file Titolare che nel file

• Se viene utilizzato un Contratto, i diritti semplici verranno utilizzati se anche codificati nella zona Titolare.(HolderProfile)

Lo schema seguente illustra, a titolo di esempio, la relazione tra posizione e diritto:

6.3. Struttura comune “Giornale trasporti” e “Eventi Speciali”

Gli eventi del Giornale Trasporti (Cr di validazione OK, di controllo ecc.) e gli eventi speciali (CR di validazione NOK…) sono codificati all’interno della stessa struttura. I dati utilizzati possono tuttavia variare da un evento Trasporto a un evento speciale.

Gli eventi del Giornale Trasporti corrispondono a informazioni che servono per il viaggio in corso. La durata di pertinenza di queste informazioni è quindi limitata.

Gli eventi speciali corrispondono a informazioni che devono essere fornite al cliente a sua ri- chiesta. Queste informazioni pertanto sono pertinenti finché vengono consultate dal cliente. L’attribuzione della memoria riservata a questi eventi speciali non è congelata.

Elementi di dati	Posizioni			Bit	Osservazioni e valori	Status JT ES
EventDateStamp	[0]			14	Data dell’evento	O	O
EventTimeStamp	[1]			11	Ora dell’evento	O	O
Bitmap generale	[2]			28	Bitmap	O	O
EventDisplayData		[0]		8	Dati per l’esposizione	NR	NR
EventNetworkId		[1]		24	Rete	R	R
EventCode		[2]		8	Natura dell’evento	O	R
EventResult		[3]		8	Codice risultato	R	O
EventServiceProvider		[4]		8	Identità dell’operatore	O	O
EventNotokCounter		[5]		8	Contatore degli eventi anomali	R	R
EventSerialNumber		[6]		24	Numero di serie dell’evento	R	R
EventDestination		[7]		16	Destinazione dell’utente	R	R
EventLocationId		[8]		16	Luogo dell’evento	R	R
EventLocationGate		[9]		8	Identificazione del passaggio	NR	NR
EventDevice		[10]		16	Indentificazione dell’apparecchiatura	R	R
EventRouteNumber		[11]		16	Riferimento della linea	R	R
EventRouteVariant		[12]		8	Riferimento di una variante della linea	NR	NR
EventJourneyRun		[13]		16	Riferimento della missione	R	R
EventVehicleId		[14]		16	Identificativo del veicolo	R	R
EventVehicleClass		[15]		8	Tipo di veicolo utilizzato	NR	NR
EventLocationType		[16]		5	Tipo di xxxxxxxx (xxxxxxxx, xxxxxxx xx xxx…)	XX	XX
EventEmployee		[17]		240	Codice del dipendente connesso	NR	NR
EventLocationReference		[18]		16	Riferimento del luogo dell’evento	NR	NR
EventJourneyInterchanges		[19]		8	Numero di coincidenze	R	R
EventPeriodJourneys		[20]		16	Numero di viaggi effettuati	NR	NR
EventTotalJourneys		[21]		16	Numero totale di viaggi autorizzati	NR	NR
EventJourneyDistance		[22]		16	Distanza percorsa	NR	NR
EventPriceAmount		[23]		16	Importo in questione legato all’evento	R	R
EventPriceUnit		[24]		16	Divisa dell’importo in questione	NR	NR
EventContractPointer		[25]		5	Riferimento del contratto in questione	R	R
EventAuthenticator		[26]		16	Codice di sicurezza, la dimensione dei campi passa	R	R
EventData		[27]		5	Bitmap	R	R
EventDataDateFirstStamp			[0]	14	Data della prima salita	R	R
EventDataTimeFirstStamp			[1]	11	Ora della prima salita	R	R
EventDataSimulation			[2]	1	Ultima validazione (0=normale, 1=degradata)	R	R
EventDataTrip			[3]	2	Troncone	R	R
EventDataRouteDirection			[4]	2	Senso	R	R

6.4. Struttura elenco degli “Eventi Speciali”

Le posizioni di memoria per questi eventi non sono specifici di un trasportatore, la struttura Li- steEvenementSpeciaux permette di accelerare la ricerca determinando la presenza o no di un evento speciale, specifico di un operatore, sulla carta.

Elementi di dati	Posizione			Bits	Osservazioni e valori	Status
SpecialEventNumber	[0]			4	Numero di eventi speciali effettivi	Obblig
SpecialEvent		[0] a [3]		4	Bitmap
SpecialEventNetworkId			[0]	24		Rif
SpecialEventProvider			[1]	8	Operatore	Obblig
SpecialEventSeriousness			[2]	2	Livello di severità	Obblig
SpecialEventPointer			[3]	5	Indicatore di eventi speciali	Obblig

NOTA In funzione della carta scelta, la dimensione riservata agli eventi speciali è differente (116 o 232 bit). Le carte gestiscono attualmente al massimo tre eventi speciali.

6.5. Struttura Elenco dei contratti

La struttura ListeContrats permette di accelerare la ricerca dei contratti sulla carta. La lettura di questa struttura permette all’operatore di determinare quali sono i contratti che si trovano sulla carta.

Elementi di dati	Posizioni			Bit	Osservazioni e valori	Stato
BestContracts	[0]			4	Numero di contratti effettivi	Obblig
BestContract		Da 0 a N [n]		3	Bitmap
BestContractNetworkId			[0]	24		Rif
BestContractTariff			[1]	4	Chiave di ricerca contratto	Ob- blig
				8	Contratto
				4	Tipo di contratto
Priorità del contratto			[2]	5	Puntatore al contratto	Obblig

A seconda del valore della variabile “Chiave di ricerca del contratto”, il significato è differente.

• 0’ : multimodale;

• ‘1’..’14’ : operatore o gruppo di operatori;

• .’15’ : si riferisce al valore di ContractProvider

Questa distinzione permette in particolare la codifica di un numero sufficiente di fornitori di ser- vizio, Il meccanismo utilizzato è il seguente:

La variabile ContractProvider nel contratto diventa subordinata al valore della chiave di ricerca Contratto. Questa subordinazione permette di codificare 241 valori di operatori o di gruppi di operatori. Questo meccanismo permette di codificare in totale 255 valori di operatori o di gruppi di operatori e rimane compatibile con i dati definiti in Intercode 1, EventServiceProvider e Spe- cialEventProvider, codificati su 8 bit nella struttura Eventi e Eventi Speciali.

Le strutture Eventi e Eventi speciali non dispongono di una chiave di ricerca contratto, la codifi- ca degli operatori è pertanto limitata a 255.

Al valore 15 della struttura BestContractTariff possono corrispondere 241 valori nella struttura Con- tratto. Si avrà pertanto la seguente corrispondenza:

Valore della chiave di ricerca Contratto	Valore del ContractProvider	Fornitore del servizio
15	15	Urbano 1
15	16	Urbano 2
15	17	Interurbano 1
15	…	Urbano n

6.6. Struttura di un Contratto

La struttura logica Contratto serve a codificare i diritti e i titoli.

Si possono utilizzare due tipi di strutture: PublicTransportContract o Contract completandoli se necessario con una struttura di dati complementari liberi prevista dal documento (ContractData).

Struttura PublicTransportContract

Elementi di dati	Posizioni		Bit	Osservazioni e valori	Status
PublicTransportContract			7	Bitmap generale	Obblig
ContractProvider	[0]		8	Compagnia che assicura il servizio per il contratto	Obblig
ContractTariff	[1]		16	Codice tariffa del contratto	Obblig
ContractSerialNumber	[2]		32	Numero di serie del contratto	Rif
ContractPassengerClass	[3]		8	Classe di servizio dei passeggeri Numero di profilo dei passeggeri	Rif

ContractValidityInfo	[4]		2	Bitmap	Rif
ContractValidityStartDate		[0]	14	Data di inizio validità del contratto	Rif
ContractValidityEndDate		[1]	14	Data di fine validità del contratto	Rif
ContractStatus	[5]		8	Stato del contratto	Obblig
ContractData	[6]			Dati supplementari	Rif

Struttura “Contract”

Tipo del Contratto (valore hex): ‘FF’h

Elementi di dati	Posizioni		Bit	Osservazioni e valori	Status
Contratto			20	Bitmap generale	O
ContractNetworkId	[0]		24	Identificazione della rete	R
ContractProvider	[1]		8	Identificazione dell’operatore	O
ContractTariff	[2]		16	Codice tariffa	O
ContractSerialNumber	[3]		32	Numero TCN	R
ContractCustomerInfoBitmap	[4]		2	Bitmap	R
ContractCustomerProfile		[0]	6	Posizione del titolare o tariffa ridotta applicabi- le	R
ContractCustomerNumber		[1]	32	Numero di cliente	NR
ContractPassengerInfoBitmap	[5]		2	Bitmap	NR
ContractPassengerClass		[0]	8	Classe di servizio dei passeggeri Numero di profilo dei passeggeri	NR
ContractPassengerTotal		[1]	8	Numero totale di passeggeri	NR
ContractVehicleClassAllowed	[6]		6	Classi di veicolo autorizzate	R
ContractPaymentPointer(0..5)	[7]		32	Puntatori agli eventi di pagamento (4 bytes)	NR
ContractPayMethod	[8]		11	Codice modalità di pagamento	R
ContractServices	[9]		16	Servizi autorizzati	R
ContractPriceAmount	[10]		16	Importo totale	R
ContractPriceUnit	[11]		16	Divisa dell’importo	R
ContractRestrictionBitmap	[12]		7	Bitmap	R
ContractRestrictStart		[0]	11	Ora di inizio di non validità durante la giornata	R
ContractRestrictEnd		[1]	11	Ora di fine di non validità durante la giornata	R
ContractRestrictDay		[2]	8	Giorno di non validità durante la settimana	R
ContractRestrictTimeCode		[3]	8	Codice dei periodi orari di non validità durante la giornata	NR
ContractRestrictCode		[4]	8	Codice di restrizione (non specificato dalla NF EN 1545 parti 1 e 2)	R
ContractRestrictProduct		[5]	16	Prodotto di restrizione (Non specificato dalla NF EN 1545 parti 1 e 2)	NR
ContractRestrictLocation		[6]	16	Riferimento del luogo di restrizione (Non speci- ficato dalla NF EN 1545 parti 1 e 2)	R
ContractValidityInfoBitmap	[13]		9	Bitmap	R
ContractValidityStartDate		[0]	14	Data di inizio validità	R
ContractValidityStartTime		[1]	11	Ora di inizio validità	R

ContractValidityEndDate		[2]	14	Data di fine validità	R
ContractValidityEndTime		[3]	11	Ora di fine validità	R
ContractValidityDuration		[4]	8	Durata di validità	R
ContractValidityLimiteDate		[5]	14	Data limite di primo utilizzo	R
ContractValidityZones(0..10)		[6]	8	Numero di zone autorizzate (0 o 1 byte)	R

Elementi di dati	Posizioni		Bit	Osservazioni e valori	Status
ContractValidityJourneys		[7]	16	Numero di viaggi autorizzati (contatore)	R
ContractPeriodJourneys		[8]	16	Numero di viaggi autorizzati per periodo (contatore)	R
ContractJourneyData	[14]		8	Bitmap	R
ContractJourneyOrigin		[0]	16	Codice luogo di origine	R
ContractJourneyDestination		[1]	16	Codice luogo di destinazione	R
ContractJourneyRouteNumbers (0..10)		[2]	16	Numeri delle linee autorizzate (2 byte)	R
ContractJourneyRouteVariants( 0..10)		[3]	8	Varianti ai numeri delle linee autorizzate (1 byte)	NR
ContractJourneyRun		[4]	16	Riferimento del viaggio	NR
ContractJourneyVia		[5]	16	Codice luogo di transito	R
ContractJourneyDistance		[6]	16	Distanza	NR
ContractJourneyInterchanges		[7]	8	Numero di coincidenze autorizzate	R
ContractSaleData	[15]		4	Bitmap	R
ContractValiditySaleDate		[0]	14	Data di vendita	R
ContractValiditySaleTime		[1]	11	Ora di vendita	R
ContractValiditySaleAgent		[2]	8	Identificazione dell’operatore di vendita	R
ContractValiditySaleDevice		[3]	16	Identificazione del terminale di vendita	R
ContractStatus	[16]		8	Stato del contratto	O
ContractLoyaltyPoints	[17]		16	Numero di punti fedeltà	NR
ContractAuthenticator	[18]		16	Codice di controllo dell’integrità dei dati	O
ContractData(0..255)	[19]		0	Dati supplementari	R

Sono possibili cinque strutture di dati supplementari CONTRACTDATA differenti:

• Abbonamento multimodale AT+, AEEA +

• Multimodale

• URBANA

• Carnet X viaggi

• URBANA/INTERURBANA

Struttura dati di un abbonamento multimodale AT+, AEEA +:

Allo scopo di ottimizzare al massimo lo spazio di memoria allocato per ciascun contratto, la zona data non utilizza bitmap per identificare i campi presenti.

Conviene dunque identificare la struttura completa di un contratto tramite un’altra variabile: questa identificazione si ritrova in BestContractTariff (tipo di contratto) della struttura Elenco dei Contratti.

Elementi di dati	Posizioni		Bit	Osservazioni e valori
ContractDataValidityJourneys		[0]	16	Numero di viaggi autorizzati (contatore)
ContractDataJourneyOrigin		[1]	16	Codice luogo di origine
ContractDataJourneyDestination		[2]	16	Codice luogo di destinazione
ContractDataJourneyVia		[3]	16	Codice luogo di passaggio
ContractDataJourneyOrigin2		[4]	16	Codice luogo di origine (caso di una seconda O/D possibile)
ContractDataJourneyDestination2		[5]	16	Codice luogo di destinazione (caso di una seconda O/D
ContractDataJourneyVia2		[6]	16	Codice luogo di passaggio (caso di una seconda
ContractDataJourneyDistance		[7]	16	Distanza
ContractDataValidityDuration		[8]	8	Durata di validità
ContractDataValidityZoneOrigin		[9]	8	Zone di validità definite a partire dall’origine
ContractDataValidityZoneDestination		[10]	8	Zone di validità definite a partire dalla destinazione
ContractDataPayMethod		[11]	11	Codice modalità di pagamento
ContractDataPriceAmount		[12]	16	Importo totale
ContractDataSaleDate		[13]	14	Data di vendita
ContractDataSaleTime		[14]	11	Ora di vendita
ContractDataSaleAgent		[15]	8	Identificazione dell’operatore di vendita
ContractDataSaleDevice		[16]	16	Identificazione dell’apparecchiatura di vendita
ContractDataLinkedContract		[17]	5	Puntatore al contratto collegato
ContractDataReceiptDelivered		[18]	1	Indicatore del giustificativo emesso
ContractDataScreen		[19]	8	Video del portatile
ContractDataException		[20]	2	Indicatore di intervento del venditore sulla tariffa del prodotto
ContractDataProxy		[21]	20	Codice mandatario
ContractDataType		[22]	4	Codice tipo incasso
ContractDataRate		[23]	7	Imposta sull’incasso
ContractDataAmount		[24]	16	Importo incassato
ContractDataNumber		[25]	47	Numero di contratto di incasso
ContractDataProxyReversion		[26]	2	Indicatore di incasso della prestazione associata
ContractDataVehicleAllowed		[27]	4	Tipo di trasporto utilizzato
ContractDataLimitDate		[28]	14	Data massima di prima validazione

Struttura multimodale

Tipo del Contratto (valore hex): ‘20’h per la struttura multimodale

Le funzionalità prese in considerazione da questa nuova struttura sono le seguenti:

• restrizioni O/D;

• restrizioni di zona;

• restrizioni temporali;

• restrizioni di utilizzo (carnet, forfait limitato ecc.) ;

• restrizioni sul numero di passeggeri.

Questa nuova struttura si basa sulla struttura PublicTransportContract della normativa NF EN 1545 parti 1 e 2.

Una nuova definizione e un nuovo funzionamento della zona “Data” permettono di codificare l’insieme dei dati che caratterizzano un titolo multimodale (più operatori).

Struttura multimodale

Tipo del Contratto (valore hex): ‘20’h per la struttura multimodale:

Elementi di dati	Posizioni		Bit	Osservazioni e valori
PublicTransportContract			7	Bitmap
ContractProvider	[0]		8	Operatore o gruppo di operatori che assicurano il servizio per il contratto
ContractTariff	[1]		16	Codice tariffa del contratto
ContractSerialNumber	[2]		32	Numero di serie del contratto
ContractPassengerClass	[3]		8	Classe di servizio
ContractValidityInfo	[4]		2	Bitmap
ContractValidityStartDate		[0]	14	Data di inizio validità del contratto
ContractValidityEndDate		[1]	14	Data di fine validità del contratto
ContractStatus	[5]		8	Stato del contratto
ContractData	[6]
ContractDataExtendedMapping			10	Bitmap
ContractDataOVD1		[0]		Restrizioni in seguito a OVD1
ContractDataJourneyOrigin1			16	Codice luogo di origine
ContractDataJourneyVia1			16	Codice luogo di transito
ContractDataJourneyDestination1			16	Codice luogo di destinazione
				ContractDataOD2		[1]		Restrizioni in seguito a OD2
ContractDataJourneyOrigin2			16	Codice luogo di origine2
ContractDataJourneyDestination2			16	Codice luogo di destinazione2
				ContractDataValidityZones		[2]		Restrizioni di zona;
ContractDataValidityZone1			8	Zone autorizzate – 8 al massimo
ContractDataValidityZone2			8	Zone autorizzate – 8 al massimo
ContractDataSale		[3]		Dati di vendita
ContractDataSaleDate			14	Data di vendita
ContractDataSaleDevice			16	Apparecchiatura di vendita
ContractDataSaleAgent			8	Operatore che ha effettuato la vendita
ContractDataPay		[4]		Dati di pagamento
ContractDataPayMethod			11	Mezzo di pagamento
ContractDataPriceAmount			16	Prezzo di vendita
ContractDataReceiptDelivered			1	Indicatore del giustificativo emesso
ContractDataPassengerTotal		[5]	6	Numero di passeggeri (gruppo)
ContractDataPeriodicity		[6]		Restrizione nel numero di passeggeri per periodo
ContractDataEndPeriod			14	Data di fine periodo
ContractDataSoldPeriod			6	Saldo del viaggio nel periodo
ContractDataSold		[7]		Gestione di titoli a scalare
ContractDataSoldX			8	Saldo di viagigi o unità (contatore)
ContractDataDebitSoldX			5	Valore del debito in viaggi o unità al momento della validazione
ContractDataVehicleAllowed						[8]	4	Tipo di trasporto utilizzato
ContractDataLinkedContract		[9]	5	Puntatore al profilo

La parte inferiore della tabella precedente (in grigio) rappresenta i nuovi dati di questa struttura. Questi dati, detti “Data”, sono raggruppati in sottogruppi: questi sottogruppi sono in numero di 10:

• O/D senza percorso;

• O/D con percorso;

• zone;

• informazioni di vendita;

• informazioni di pagamento;

• numero di passeggeri;

• periodi di validità;

• contatori di diritti;

• trasporto utilizzato;

• puntatore verso un profilo;

La bitmap che precede questi dati (ContractDataExtendedMapping) permette di determinare i sot- togruppi presenti e i sottogruppi assenti. A ciascun bit corrisponde un sottogruppo. Questo mecca- nismo di bitmap permette di garantire un minimo di semplicità nella redazione di un’istanza. Co- munque, i campi Data non sono congelati: per una stessa struttura, si possono avere istanze diffe- renti a seconda del valore del bitmap.

Attenzione: ciascun sottogruppo indicato come presente compare integralmente nella struttura. Comunque, se il bit corrispondente alle informazioni di vendita (ContractDataSale) è 1, i campi ContractDataSaleDate, ContractDataSaleDevice eContractDataSaleAgent devono essere compila- ti.

Dettaglio dei dati:

La variabile ContractDataExtendedMapping rappresenta il bitmap della struttura Data. Essa funziona come segue:

ContractDataExtendedMapping = ‘jihgfedcba’

Bit a: 0 = ContractDataOVD1 assente ; Bit a : 1 = ContractDataOVD1 presente Bit b : 0 = ContractDataOD2 assente ; Bit b : 1 = ContractDataOD2 presente

Bit c : 0 = ContractDataValidityZones assente ; Bit c : 1 = ContractDataValidityZones presente Bit d : 0 = ContractDataSale assente ; Bit d : 1 = ContractDataSale presente;

Bit e : 0 = ContractDataPay assente ; Bit e : 1 = ContractDataPay presente

Bit f : 0 = ContractDataPassengerTotal2 assente; Bit f : 1 = ContractDataPassengerTotal2 presente

Bit g : 0 = ContractDataPeriodicity assente ; Bit g : 1 = ContractDataPeriodicity presente Bit h : 0 = ContractDataSold assente ; Bit h: 1 = ContractDataSold presente

Bit i : 0 = ContractDataVehicleAllowed assente ; Bit i : 1 = ContractDataVehicleAllowed presente Bit j : 0 = ContractDataLinkedContract assente ; Bit j : 1 = ContractDataLinkedContract presente

Le variabili ContractDataValidityZone1 e ContractDataValidityZone2 sono ciascuna codificata su 8 bit, ciascun bit corrisponde a una zona. Questa codifica fino a 16 zone permette di garantire l’evoluzione dell’istanza verso una tariffazione alveolare.

	ContractDataValidityZone1	ContractDataValidityZone2
Restrizioni di zona 1;	'00000001'	'00000000'
Restrizioni di zona 2 & 4;	'00001010'	'00000000'
Restrizioni di zona 10;	'00000000'	'00000010'

Le variabili ContractDataEndPeriod e ContractDataSoldPeriod permettono di gestire un numero limitato di tragitti durante un periodo stabilito. Inoltre ContractDataEndPeriod riprende la data limite di validità associata al numero di diritti restanti nel periodo (ContractDataSoldPeriod).

La variablie ContractDataSoldX riprende il numero di titoli ancora validabili in caso di un’andata- ritorno o di un carnet di biglietti; essa è associata all’utilizzo di un computer protetto (vedere 7.6). La variabile ContractDataDebitSoldX permette di gestire il viaggio di gruppo precisando il valore dell’ultima scalatura (1 per un viaggiatore singolo).

Esempio di codifica

Ecco alcuni esempi di istanza di questa struttura nei casi seguenti

1) biglietto unitario di zona;

2) carnet di x biglietti di zona;

3) forfait limitato di zona

4) forfait illimitato di zona

Elementi di dati	Posi-		Bit	Commenti	1	2	3	4
PublicTransportContract Bitmap			7	Bitmap	7	7	7	7
ContractProvider	[0]		8	Operatore o gruppo di operatori che assi- curano il servizio per il contratto	8	8	8	8
ContractTariff	[1]		16	Codice tariffa del contratto	16	16	16	16
ContractSerialNumber	[2]		32	Numero di serie del contratto	32	32	32	32
ContractPassengerClass	[3]		8	Classe di servizio
ContractValidityInfo	[4]		2	Bitmap			2	2
ContractValidityStartDate		[0]	14	Data di inizio validità del contratto			14	14
ContractValidityEndDate		[1]	14	Data di fine validità del contratto			14	14
ContractStatus	[5]		8	Stato del contratto	8	8	8	8
ContractData	[6]
ContractDataExtendedMapping			10	Bitmap	10	10	10	10
ContractDataOVD		[0]		Restrizioni in seguito a OVD1
ContractDataJourneyOrigin			16	Codice luogo della prima origine
ContractDataJourneyVia			16	Codice luogo del primo tragitto
ContractDataJourneyDestination			16	Codice luogo della prima destinazione
ContractDataOD2		[1]		Restrizioni in seguito a OD2
ContractDataJourneyOrigin2			16	Codice luogo di origine 2	16
ContractDataJourneyDestination2			16	Codice luogo di destinazione 2	16
ContractDataValidityZones		[2]		Restrizioni di zona
ContractDataValidityZone1			8	Zone autorizzate – 8 al massimo	8	8	8	8
ContractDataValidityZone2			8	Zone autorizzate – 8 al massimo	8	8	8	8
ContractDataSale		[3]		Dati di vendita
ContractDataSaleDate			14	Data di vendita	14	14	14	14
ContractDataSaleDevice			16	Apparecchiatura di vendita	16	16	16	16
ContractDataSaleAgent			8	Operatore che ha effettuato la vendita	8	8	8	8
ContractDataPay		[4]		Dati di pagamento
ContractDataPayMethod			11	Mezzo di pagamento	12	12	12	12
ContractDataPriceAmount			16	Prezzo di vendita	16	16	16	16
ContractDataReceiptDelivered			1	Indicatore del giustificativo emesso	1	1	1	1
ContractDataPassengerTotal2		[5]	6	Numero di passeggeri (gruppo)
ContractDataPeriodicity		[6]		Restrizione nel numero di passeggeri per periodo
ContractDataEndPeriod			14	Data di fine periodo			14
ContractDataSoldPeriod			6	Saldo del viaggio nel periodo			6
ContractDataSold		[7]		Gestione di titoli a scalare
ContractDataSoldX			8	Saldo di viaggi o unità (contatore)		8
ContractDataDebitSoldX			5	Valore del debito in viaggi o unità al mo- mento della validazione		5
ContractDataVehicleAllowed		[8]	4	Tipo di trasporto utilizzato		4	4	4
ContractDataLinkedContract		[9]	5	Puntatore al profilo			5	5

Totale in bit 196 181 223 203

Riferimento geografico

In un contesto multimodale (Urbano, Interurbano dipartimentale, TER regionale) le diverse restri- zioni a livello di contratto devono essere referenziate in modo omogeneo. Esso si compone delle variabili:

• ContractDataJourneyxxx: codice luogo

• ContractDataValidityZone1 e ContractDataValidityZone2 : zona(e) autorizzata(e)

Per l’uso condiviso di una tale struttura, si dovrà, all’interno di un NetworkId, accordarsi bene su questa referenza per adottare una codifica unica di queste variabili

Nella pratica, possiamo utilizzare una nozione di fermata tariffaria che è più estesa della fermata fisica (stazione, palina ecc.). Questa nozione di fermata tariffaria può, ad esempio, essere assimi- lata a comuni o quartieri.

Struttura Dati di un contratto urbano:

Tipo del Contratto (valore hex): ‘40’h per un diritto Tipo del Contratto (valore hex): ‘41’h per un titolo

Elementi di dati	Posizioni		Bit	Osservazioni e valori	Tipo di viaggio
ContractDataPayMethod	[0]		11	Codice modalità di pagamento	X
ContractDataPriceAmount	[1]		16	Importo totale	X
ContractDataSaleDate	[2]		14	Data di vendita	X
ContractDataSaleTime	[3]		11	Ora di vendita	X
ContractDataSaleAgent	[4]		8	Identificativo dell’operatore di vendita	X
ContractDataSaleDevice	[5]		16	Identificativo dell’apparecchiatura	X
ContractDataReceiptDelivered	[6]		1	Indicatore del giustificativo emesso	X
ContractDataPassengerTotal	[7]		8	Numero di persone del gruppo	X
ContractDataEndInhibitionDate	[8]		14	Data di sospensione dell’inibizione	X

Tipo del Contratto (valore hex): ‘43’h per un contratto profilo

Tipo del Contratto (valore hex): ‘44’h per un contratto senza contatore Tipo del Contratto (valore hex): ‘45’h per un contratto con contatore

Elementi di dati	Posizioni		Bit	Osservazioni e valori
PublicTransportContract Bitmap			7	Bitmap
ContractProvider	[0]		8	Operatore o gruppo di operatori che assicurano il ser- vizio per il contratto
ContractTariff	[1]		16	Codice tariffa del contratto
ContractSerialNumber	[2]		32	Numero di serie del contratto
ContractPassengerClass	[3]		8	Classe di servizio
ContractValidityInfo	[4]		2	Bitmap
ContractValidityStartDate		[0]	14	Data di fine validità del contratto
ContractValidityEndDate		[1]	14	Data di fine validità del contratto
ContractStatus	[5]		8	Stato del contratto
ContractData	[6]		0
ContractDataExtendedMapping			16	Bitmap
ContractDataSaleAgent		[0]	8	Operatore che ha venduto il contratto
ContractDataSaleSecureDevice		[1]	32	Numero di serie del SAM (32 bit)
ContractDataSaleDate		[2]	14	Data di carico iniziale del contratto
ContractDataSaleTime		[3]	11	Ora di carico iniziale del contratto
ContractDataReloadDate		[4]	14	Data di ricarica del contratto
ContractDataJourneyRouteNumbers		[5]	50	5 linee autorizzate (0= campo non significativo) Codifica di una linea su 10 bit
ContractDataJourneyRouteVariants		[6]	8	1 troncone autorizzato (0=campo non significativo)
ContractDataValidityLimitDate		[7]	14	Data limite per un primo utilizzo del contrat- to Utilizzato principalmente per i contratti la cui Contrac- tEndValidityDate è calcolata a partire dalla prima vali-
ContractDataEndInhibitionDate		[8]	14	Data fino alla quale la ricerca in lista nera dei contratti è inibita. Questo permette di poter disporre di un ritardo per l’aggiornamento della lista nera dei contratti in seguito
ContractDataReferenceEndActivationDate		[9]	14	Prima data linite di attività (DEA) che viene prorogata della durata di attivazione(in generale un anno)
ContractDataActivationBitMap		[10]	8	Campo di bit: 1 bit per unità di durata di attivazione (1 anno/bit). Permette di prorogare la data di attivazione della durata di attivazione (un anno), Ciascun bit può passare da 0 a 1 disponendo unicamente delle chiavi
ContractDataTimetable		[11]	4	N. del calendario
ContractDataInhibition		[12]	1	Boolean che indica (=1) che il contratto è provvisoria- mente invalido a seguito di una posizione sulla lista nera dei contratti. La riattivazione è possibile unica- mente allo sportello con le chiavi di vendita.
ContractDataPassengerTotal3		[13]	4	Numero di persone del gruppo. Se questo numero è omesso, il contratto è validabile per una sola persona.
ContractDataRightsCounter		[14]	8	Saldo del contatore dei diritti di acquisizione (numero di cariche in vendita)
ContractDataUsed		[15]	1	=1 se il contratto è stato validato almeno una volta
			330

Data limite di attività (DEA) Durata di attività di un contratto:

Per un contratto, si può definire una data limite di attività (DEA). Essa permette di inibire

“l’attività” del contratto se viene superata. D’altra parte, il contratto resta VALIDO se la sua DEV non è trascorsa. Questo significa che non è cancellabile da un altro “Provider”. E può essere riattivato nel momento in cui l’utente regolarizza la sua situazione. In effetti, questa data è prorogata sulle apparecchiature di validazione grazie alla presenza del N. di contrat- to in lista (bianca o di altro colore!). La proroga si effettua sempre per unità di durata di atti- vazione (in generale un intero anno). Ad esempio: La sospensione di un contratto studente alla fine dell’anno scolastico al momento del pagamento di un nuovo anno. E la riattivazio- ne della sua validità (senza tornare allo sportello) a seguito del pagamento effettuato. Que- sta DEA può essere prorogata:

• prima che sia scaduta;

• dopo che è spirata, ma con un’interruzione di servizio di trasporto o un servizio di trasporto degradato finché la DEV non viene rinnovata.

Operazioni sulla DEA

Operazione	Descrizione
Inizializzazione	Al momento del carico, la DEA viene inizializzata alla data di fine della prima attività
DEV Contratto	Al momento della vendita, in generale la DEV è inizializzata a: Prima DEA + N (max 8) anni.
Proroga	La DEA è prorogabile su un’apparecchiatura di validazione, tramite la lista (bianca) dei N. di contratto: DEA = DEA + 1 anno. NB1 : la durata di attività è fissa: 1 an- no.
Soppressione	Con il contratto.

Impianto della DEA

La difficoltà è quella di prolungare il contratto su un validatore che non possiede le chiavi di vendita. Questo impone di mettere in funzione un “campo di flag” che permettono di attivare anni utilizzando un meccanismo di sicurezza che autorizzi la forzatura da 0 a 1 (ma non l’inverso) di bit di dati di un contratto tramite le chiavi dell’apparecchiatura di validazione.

Su ciascuna validazione, la DEA è calcolata (per testare se è attiva) a partire dai flag anno e dalla prima DEA :

DEA = prima DEA memorizzata sul contratto + (Numero di flag a uno x 1 anno)

La DEA è prorogata se il contratto appartiene alla lista bianca e se la sua DEA è inferiore alla data di proroga situata nell'elenco. Questo elenco possiede la seguente struttura:

Data di proroga della DEA, elenco dei contratti da prolungare.

Inizio white list:

Data1 di proroga;

Elenco dei N. di contratto;

Data2 di proroga;

Elenco dei N. di contratto;

…

…

Data N di proroga;

Elenco dei N. di contratto;

Fine della white list;

Diritto di acquisizione

Alla vendita, il contratto può autorizzare (tramite i parametri dell’apparecchiatura di vendita) il carico di altri contratti. Questo carico può essere limitato di numero tramite un contatore detto “contatore dei diritti di acquisizione”. Contatore di diritti di acquisizione (di carico) = Contatore del numero di contratti che è possibile (autorizzato) caricare per questo contratto. In generale, questo contatore non è ricaricabile. Questo contatore è inizializzato al numero di diritti di ac- quisizione (numero di cariche), e dopo decrementato a ciascun carico di un contratto autoriz- zato. Nel momento in cui il contatore è esaurito, il contratto non permette il carico di altri con- tratti.

Ad esempio: il diritto di acquisizione permette di autorizzare per il contratto di un operatore A, l’acquisto di un certo numero di contromarche di un operatore B.

Struttura dati di un carnet X di viaggi

Tipo del Contratto (valore hex): ‘42’h per un contratto con carnet di X viaggi

Struttura ListeContrats

N.	Elementi di dati	Osservazioni e valori
…	…	…
502	BestContractTariff	Identificativo dell’operatore di vendita
503		Tipo di contratto = ‘42’h
504		Priorità del contratto=’9’h
…	…	…

Struttura Contratti

Elementi di dati	Posizioni		Bit	Commenti + valori di carico
MainPublicTransportContractBitm ap			7	Bitmap (‘111'111’b)
ContractProvider	[0]		8	Identificativo dell’operatore
ContractTariff	[1]		16	Codice della tariffa
ContractSerialNumber	[2]		32	Numero di serie del contratto
ContractPassengerClass	[3]		8	Classe di servizio
ContractValidityInfoBitmap	[4]		2	Bitmap (‘11’b)
ContractValidityStartDate		[0]	14	Data di inizio validità = 00
ContractValidityEndDate		[1]	14	Data di fine validità = giorno di validazione
ContractStatus	[5]		8	Stato del contratto = 00
ContractData	[6]		0
ContractDataPayMethod		[0]	11	Codice modalità di pagamento = 00
ContractDataPriceAmount		[1]	16	Importo totale = 00
ContractDataSaleDate		[2]	14	Data di vendita = data di carico
ContractDataSaleTime		[3]	11	Ora di vendita = ora di carico
ContractDataSaleAgent		[4]	8	Identificativo dell’operatore di vendita
ContractDataSaleDevice		[5]	16	Identificativo dell’apparecchiatura di vendita
ContractDataReceiptDelivered		[6]	1	Indicatore del giustificativo emesso = 00
ContractDataPassengerTotal		[7]	8	Numero di persone del gruppo = 01
ContractDataEndInhibitionDate		[8]	14	Data di sospensione dell’inibizione = 00
			208

ContractProvider 1 primo operatore, 2 = ., 3 = terzo operatore

ContractSerialNumber Questo numero è costituito dal numero di seconde vendite dopo il 1/1/1997.

ContractTariff = numero di contratto (53 per Indre et Loire)

ContractValidityStartDate prende il valore ‘00’h all’emissione del titolo. Vedere il ciclo di vi- ta per gli altri valori.

ContractValidityEndDate = giorno di validazione del contratto

ContractStatus prende il valore ‘00’h all’emissione del titolo. Vedere il ciclo di vita per gli a tri valori.

ContractDataPayMethod: Definisce il mezzo di pagamento utilizzato per pagare il contratto.

ContractDataPriceAmount: Importo totale del contratto.

ContractDataSaleDate: Data di rilascio del contratto.

ContractDataSaleTime: Ora di rilascio del contratto.

ContractDataSaleAgent: identificazione dell’operatore che ha rilasciato il contratto.

ContractDataSaleDevice: Identificazione dell’apparecchiatura che ha rilasciato il contratto.

ContractDataReceiptDelivered: Questo campo è l’indicatore “giustificativo emesso” (‘0’b = no, ‘1’b = sì): Indica se un giustificativo è stato rilasciato o no alla creazione del contratto o successivamente.

ContractDataPassengerTotal = ‘00000001’b all’emissione del contratto

ContractDataEndInhibitionDate = ‘00000000000000’b all’emissione del contratto

+ 1 Contatore protetto X: viaggi associati al contratto

Struttura Dati di un contratto urbano/interurbano Tipo del Contratto (valore hex): 50'h

Per ciascun tipo di mappatura corrispondente a famiglie di contratti (per viaggi, abbonamenti, abbonamenti limitati, scolari convenzionati ecc.) la struttura contratto è comune all’insieme dei vari tipi di contratti della gamma tariffaria. Il bitmap “ContractDataExtendedMapping” permette di definire i differenti gruppi di dati utilizzati per un tipo di contratto (vedere gli esempi di contratti alla fine della tabella).

1 : abbonamento interurbano restrizione OVD + 2 viaggi per giorno + restrizione settimanale 2 : carnet a viaggi limitati in numero di sezioni

3 : abbonamento restrizione due OD + due linee 4 : abbonamento urbano x viaggi y giorni

5 : carta a valore trasporto

Elementi di dati	Poszioni		Bit	Osservazioni e valori	1	2	3	4	5
PublicTransportContract			7	Bitmap generale	7	7	7	7	7
ContractProvider	[0]		8	Compagnia che assicura il servizio per il contratto	8	8	8	8	8
ContractTariff	[1]		16	Codice tariffa del contratto	16	16	16	16	16
ContractSerialNumber	[2]		32	Numero di serie del contratto
ContractPassengerClass	[3]		8	Classe di servizio dei viaggiatori
ContractValidityInfo	[4]		2	Bitmap
ContractValidityStartDate		[0]	14	Data di inizio validità del contratto
ContractValidityEndDate		[1]	14	Data di fine validità del contratto
ContractStatus	[5]		8	Stato del contratto	8	8	8	8	8
ContractData	[6]		0	Dati complementari
ContractDataValidityEndDate			14	Data di fine validità del contratto	14	14	14	14	14
ContractDataGreyList			14	Trattamento in lista grigia	14	14	14	14	14
ContractDataChrono			16	Chrono	16	16	16	16	16
ContractDataFlag			2	Flag di telemodifica	2	2	2	2	2
ContractDataExtendedMapping			16	Bitmap	16	16	16	16	16
ContractDataSaleAgent		[0]	8	Identificativo dell’operatore di vendita	8	8	8	8
ContractDataGeoOVD		[1]		Restrizioni conseguenti a OVD
ContractDataJourneyOrigin_1			14	Codice fermata di origine in collegamento con il back office	14
ContractDataJourneyDestination_1			14	Codice fermata di destinazione in collegamento con il back office	14
ContractDataJourneyVia			14	Codice fermata di transito in collegamento con il back office	14
NamedToken		[2]
ContractDataTokenNumber1			16	Numero di coupon in collegamento con il back office		16		16
ContractDataTokenNumber2			16	Numero di coupon in collegamento con il back office		16		16
ContractDataAutoloadDateStart			14	Data di inizio dell’autoload		14		14

Elementi di dati	Posi-		Bit	Osservazioni e valori	1	2	3	4	5
ContractDataAutoloadDateStop			14	Data di fine dell’autoload		14		14
SoldX		[3]
ContractDataSoldX			8	Saldo in viaggi o unità		8		8
ContractDataDebitSoldX			5	Valore del debito in viaggi o unità		5		5
Tpurse		[4]
ContractDataTPurse			19	Importo del portamonete trasporto					19
ContractDataDebitTPurse			16	Valore del debito portamonete trasporto					16
ContractDataPassengerTotal2		[5]	6	Numero di viaggiatori (gruppo)					6
Z periodicity		[6]		Restrizione in numero di viaggi per periodo
ContractDataEndPeriod			14	Data di fine periodo	14			14
ContractDataSoldPeriod			6	Saldo del viaggio nel periodo	6			6
ContractDataGeoZonales		[7]		Restrizione a 3 zone al massimo
ContractDataGeoZone1			6	Numero della prima zona autorizzata in collega- mento con il back office
ContractDataGeoZone2			6	Numero della seconda zona autorizzata in colle- gamento con il back office
ContractDataGeoZone3			6	Numero della terza zona autorizzata in collega- mento con il back office
ContractDataGeoSections		[8]		Restrizione legata a un numero di sezione
ContractDataZones			6	Numero di sezioni autorizzate		6
ContractDataSoldZones			6	Numero di sezioni restanti		6
ContractDataGeoOD		[9]		Restrizione legata a due OD
ContractDataJourneyOrigin_2			14	Codice fermata di origine in collegamento con il			14
ContractDataJourneyDestination_2			14	Codice fermata di destinazione in collegamento con il back office			14
ContractDataJourneyOrigin_3			14	Codice fermata di origine in collegamento con il			14
ContractDataJourneyDestination_3			14	Codice fermata di destinazione in collegamento con il back office			14
ContractDataGeoLine		[10]		Restrizione legata a due linee
ContractDataJourneyLine1			14	Codice linea 1 in collegamento con il back office			14
ContractDataJourneyLine2			14	Codice linea 2 in collegamento con il back office			14
ContractDataResctrictHebdo		[11]	14	Restrizioni settimanali: per mezza giornata (2 bit per giorno)	14
ContractDataValidityStartDate		[12]	14	Data di inizio validità	14		14	14
ContractDataValidityEndTime		[13]	11	Ora di fine validità
ContractDataToken		[14]	4	Gettone corrispondente a un coupon semplice	4		4
ContractDataIntermodal		[15]	4	Gestione dell’intermodalità (interurbana - urbana)	4	4	4

A titolo di esempio:

L’abbonamento interurbano restrizione ODV + 2 viaggi per giorno + restrizione settimanale

(1) è codificato su 207 bit.

Il carnet a viaggi limitati in numero di sezioni (2) è codificato su 198 bit.

L’abbonamento restrizione due OD + due linee (3) è codificato su 215 bit. L’abbonamento urbano x viaggi y giorni (4) è codificato su 216 bit.

La carta a valore trasporto (5) è codificata su 142 bit. Questa struttura di contratto possiede tre tipi di dati:

1) Il complemento legato a un tipo di diritto:

• ContractDataGeoOVD : restrizione O/D con transito

• ContractDataGeoZonales: restrizione legata alle zone

• ContractDataGeoSections: restrizione legata alle sezioni

• ContractDataGeoOD: restrizione legata a due O/D

• ContractDataGeoLine: restrizione legata a due linee

• ContractDataResctrictHebdo: restrizione per mezza giornata sulla settimana

• ContractDataValidityStartDate: data di inizio validità

Queste informazioni possono essere stampate sulla carta per memorizzare unicamente que- ste restrizioni. In questo caso, il contratto non è ancora valorizzato, si deve procedere a una carica per attivarlo.

Questo complemento è generalmente utilizzato per contratti forfettari. Per carnet o biglietti individuali, il diritto definito in Holder è sufficiente. In effetti le differenti restrizioni spaziali o temporali, e la data di inizio validità, che sono nel complemento del diritto stampato nella zo- na contratto, sono utlizzati soltanto per forfait, e non per titoli unitari o carnet che non posso- no essere soggetti a restrizioni spaziali e temporali.

2) Le informazioni di validità del contratto corrente

• ContractDataValidityEndDate: data di fine validità

• ContractDataGreyList: trattamento in lista grigia (data di sospensione)

• ContractDataSoldX: saldo di viaggi o unità

• ContractDataDebitSoldX: valore dell’ultimo debito in viaggi o unità

• ContractDataTPurse: saldo di PME trasporto

• ContractDataDebitTPurse: valore dell’ultimo debito PME

• ContractDataEndPeriod: data di fine validità del periodo

• ContractDataSoldPeriod: saldo del viaggio nel periodo

• ContractDataValidityEndTime: ora di fine validità

• ContractDataIntermodal: flag di gestione dell’intermodalità

3) Informazioni di rinnovo:

• ContractDataTokenNumber : numero di gettoni che fanno riferimento a un coupon par- ticolare (ad esempio: mensile, settimanale, mese di calendario, X giorni fluttuanti, X giorni Y viaggi ecc.)

• ContractDataAutoload : informazione di gestione di prelievo automatico

• ContractDataToken : il numero di gettoni semplici ricaricati

Questo meccanismo permette di ottimizzare l’utilizzo di una zona contratto memorizzando in questa zona le informazioni complementari di restrizioni legate a un diritto (ad esempio lo scolaro il cui abbonamento convenzionato dal consiglio generale è limitato al tragitto casa- scuola), le informazioni di validità del contratto corrente (data di fine validità, saldo, valore) e le informazioni di rinnovo (gettone).

Struttura Dati di un contratto multimodale

Tipo del Contratto (valore hex): '46'h

La struttura di contratto 46h è un'evoluzione della struttura interoperabile 20h. In rapporto alla struttura 20h, essa possiede i seguenti dati supplementari;

• aggiunta del dato ContractDataValidityStartTime a. Permette di codificare una data di inizio al minuto preciso;

• aggiunta del dato ContractDataValidityEndTime a. Permette di codificare una data di fine al minuto preciso;

• aggiunta della data fino alla quale la ricerca in lista nera è inibita: ContractDataEn- dInhibitionDate a. Permette di indicare un ritardo (almeno un giorno) per l’aggiornamento della lista nera sulle apparecchiature di validazione a seguito di un’operazione di regolarizzazione allo sportello;

• aggiunta del dato ContractDataValidityLimitDate (identico al dato: ContractDataValidi- tyLimitDate) a. Permette di linitare nel tempo la prima utilizzazione di un contratto con ContractValidityEndDate fluttuante nella validazione;

• aggiunta della sottostruttura: ContractDataGeoLine a Permette di restringere a due li- nee l’utilizzo di una rete operatrice;

• aumento della dimensione del dato: ContractDataValidityJourneys (da 8 bit a 16 bit) a Permette la gestione delle carte di viaggio per le quali i saldi di unità sono aumenta- ti;

• memorizzazione del N. di XXX nel dato: ContractDataSaleSecureDevice, al momento del carico del contratto a. Permette una migliore tracciabilità al momento delle vali- dazioni.

Inoltre la dimensione del dato: ContractDataSoldPeriod della struttura 20H è stato aumenta- to: da 6 a 8 bit.

Elementi di dati	Posizione		Bit	Osservazioni e valori
PublicTransportContract Bitmap						7	Bitmap
ContractProvider	[0]		8	Operatore o gruppo di operatori che assicurano il servizio per il contratto
ContractTariff	[1]		16	Codice tariffa del contratto
ContractSerialNumber	[2]		32	Numero di serie del contratto
ContractPassengerClass	[3]		8	Classe del servizio
ContractValidityInfo	[4]		2	Bitmap
ContractValidityStartDate		[0]	14	Data di inizio validità del contratto
ContractValidityEndDate		[1]	14	Data di fine validità del contratto
ContractStatus	[5]		8	Stato del contratto
ContractData	[6]		0
ContractDataExtendedMapping			17	Bitmap
ContractDataOVD1		[0]	0	Restrizioni conseguenti a OVD 1
ContractDataJourneyOrigin1			16	Codice luogo di origine1
ContractDataJourneyVia1			16	Codice luogo di transito 1
			16	Codice luogo destinazione1

Elementi di dati	Posizione		Bit	Osservazioni e valori
ContractDataJourneyDestination1
ContractDataOD2		[1]	0	Restrizioni conseguenti a OD2
ContractDataJourneyOrigin2			16	Codice luogo origine 2
ContractDataJourneyDestination2			16	Code luogo destinazione 2
				ContractDataValidityZones		[2]	0	Restrizioni di zona
ContractDataValidityZone1			8	Zone autorizzate – 8 al massimo
ContractDataValidityZone2			8	Zone autorizzate – 8 al massimo
ContractDataSale		[3]	0	Dati di vendita
ContractDataSaleDate			14	Data di vendita
ContractDataSaleDevice			16	Apparecchiatura di vendita
ContractDataSaleAgent			8	Operatore che ha effettuato la vendita
ContractDataPay		[4]	0	Dati di pagamento
ContractDataPayMethod			11	Mezzo di pagamento
ContractDataPriceAmount			16	Prezzo di vendita
ContractDataReceiptDelivered			1	Indicatore del giustificativo emesso
ContractDataPassengerTotal		[5]	6	Numero di viaggiatori (gruppo)
ContractDataPeriodicity		[6]	0	Restrizione nel numero di passeggeri nel periodo
ContractDataEndPeriod			14	Data di fine periodo
ContractDataSoldPeriod2			8	Saldo dei viaggi nel periodo
ContractDataSold		[7]	0	Gestione dei titoli a scalare
ContractDataSoldX			8	Saldo di viaggi o unità (contatore)
ContractDataDebitSoldX			5	Valore del debito in viaggi o unità al momento di una validazione
ContractDataVehicleAllowed		[8]	4	Tipo di trasporto utilizzato
ContractDataLinkedContract		[9]	5	Puntatore verso il profilo
ContractDataValidityStartTime		[10]	11	Ora di inizio validità del contratto
ContractDataValidityEndTime		[11]	11	Ora di fine validità del contratto
ContractDataEndInhibitionDate		[12]	14	Data fino alla quale la ricerca in lista è inibita. Questo permette di disporre un ritardo per l’aggiornamento dell’elenco a seguito di un’operazione nel punto vendita.
ContractDataValidityLimitDate						[13]	14	Data limite per una prima utilizzazione del con- tratto. Utilizzato principalmente per i contratti la cui Contractvalidi- tyEndDate è calcolata al momento della prima validazione (con- tratto detto “a validazione fluttuante”)
ContractDataGeoLine		[14]	0	Restrizioni a seguito di due linee: linea 1 e linea 2
ContractDataJourneyLine1			14	Codice linea 1
ContractDataJourneyLine2			14	Codice linea 2
ContractDataValidityJourneys		[15]	16	Numero di viaggi autorizzati o unità al carico (limite di 65535 ne- cessario al contratto a viaggi) (contatore)
ContractDataSaleSecureDevice						[16]	32	Numero di SAM

La struttura 46H può utilizzare due contatori. Sono utilizzati anche:

• per la Carta Movimento 97 Struttura 2, c’è solo un contatore per contratto 46H. Il suo utilizzo è identico a quello descritto nel paragrafo 8.1: memorizzazione dei campi ContractDataValidityJourneys o ContractDataSoldX:

• la Carta Movimento 97 Struttura 3, ha solo un contatore per contratto 46H. Il suo uti- lizzo è identico a quello descritto nel paragrafo 8.2: memorizzazione dei campi Con- tractDataValidityJourneys o ContractDataSoldX:

• la Carta GTM Light possiede 9 contatori. La struttura 46H può utilizzare due contatori, dipendenti dalla posizione che essa occupa:

contratto		contatore 1	contatore 2
numero di file	registrazione	numero di file	numero di file
$2020	1	$202A	$202E
$2020	2	$202B	$202F
$2020	3	$202C	$2060
$2020	4	$202D	$2061

Per il contatore 1, il suo utilizzo è identico a quello descritto nel paragrafo 8.3: memorizza- zione dei campi ContractDataValidityJourneys o ContractDataSoldX.

Per il contatore 2, il suo utilizzo è dedicato a un conteggio per periodo: limiti sul viaggio, con- teggio di punti fedeltà ecc.

Elementi di dati	Dimensione in bit	Descrizione
CounterValidityPeriodEndDate	14	Codifica binaria che indica il numero di giorni a partire dal 1 gen- naio 1997, che viene definito il giorno 0. La data è codificata in complemento a 1 (perché il contatore completo non può essere decrementato unicamente dal validatore). Dunque aumentare la data nel tempo equivale a decrementare i bit più significativi del contatore completo e nello stesso tempo a de- crementare il valore voluto aggiornando la data
CounterPeriodBalance	20	Al momento dell’aggiornamento della data di fine periodo, contem- poraneamente si aggiorna anche il contatore per periodo al suo valore massimo o al suo valore richiesto

In questa struttura sono inseriti due dati:

• nei bit più significativi il dato (inserito a sinistra / dati più significativi): CounterValidityPe- riodEndDate che rappresenta sempre la data di fine periodo;

• nei bit meno significativi il dato (inserito a destra/dati meno significativi): CounterPe- riodBalance il saldo dell’evento per il periodo in corso che termina alla CounterValidi- tyPeriodEndDate

La carta CT 2000 Transcarte possiede nove contatori ma 8 contratti. C’è soltanto un contato- re per il contratto 46H. Il suo utilizzo è identico a quello descritto nel paragrafo 8.4: me- morizzazione dei campi ContractDataValidityJourneys o ContractDataSoldX.

7. Regole di utilizzo

7.1. Stadi del ciclo di vita

La descrizione seguente è soltanto indicativa. Essa dipende dalle funzionalità associate.

7.1.1. Personalizzazione dell’applicazione DOFOCO

L’applicazione DOFOCO è un’applicazione di trasporto nella quale l’insieme degli operatori possono scrivere dati multimodali e monomodali a condizione che rispettino i principi enunciati nel DOFOCO oltre che nel DOFOCO+. DOFOCO sta per Dossier FOnctionnel COmmun (Dossier funzionale comune) sulle specifiche funzionali di interoperabilità della bigliettazione. DOFOCO+ rappresenta le necessità delle autorità organizzatrici in materia di bigliettazione (approccio istituzionale alla bigliettazione intermodale).

7.1.1.1. Personalizzazione dell’Environment

Viene realizzata dal trasportatore che emette la carta verso gli utilizzatori.

Essa consiste nel preparare l’applicazione DOFOCO, in modo che sia utilizzabile sulle appa- recchiature che manipolano la carta. Consiste dunque nell‘aggiornare il file logico Environment con i dati obbligatori (vedere 6.1). Fra le altre cose si definiscono la rete, la versione di appli- cazione ecc.

7.1.1.2. Personalizzazione del titolare della carta

Questa personalizzazione consiste nell’introdurre nella carta le informazioni riguardanti il titola- re al quale la carta è stata rilasciata. Consiste dunque nel:

• creare il file del Titolare, dove va scritto almeno:

o Il tipo di carta (carta anonima, carta nominativa ecc.) ;

o la data di nascita del titolare, se si tratta di una carta nominativa, altrimenti il campo non è presente nella struttura in accordo con il tipo di carta.

7.1.2. Identificazione e autenticazione

Alla presentazione della carta da parte del cliente, si può verificare:

• lettura dell’ATR (Answer To Reset) della carta (L’ATR è il flusso di dati che restituisce la carta nel momento in cui viene messa sotto tensione);

• i dati restituiti dall’ATR corrispondono a una carta riconosciuta?

• la carta è stata invalidata?

• c’è un’applicazione trasporto sulla carta?

• il numero di serie della carta è sulla lista nera?

• l’applicazione trasporto è invalidata?

• l’applicazione è validabile qui (numero di versione e rete relativa)?

• l’applicazione è inoltre validabile ora (data di fine applicazione)?

7.1.3. Distribuzione

Una sessione di vendita si scompone nel modo seguente:

1) Identificazione della carta.

2) Soppressione dei contratti cancellati:

• PRINCIPIO GENERALE DI AGGIORNAMENTO ALLO STATO “CANCELLABILE” DI UN CONTRATTO (vedere 7.2.2);

• REGOLE DI SOSTITUZIONE DI UN CONTRATTO CANCELLABILE (vedere 7.3);

• SOPPRESSIONE DI UN CONTRATTO (vedere 7.4).

3) Scelta del/o dei titoli da scrivere sulla carta.

4) Pagamento

5) Emissione del o dei titoli di trasporto:

• REGOLE DI SCRITTURA DEL FILE BESTCONTRACTS (vedere 7.7);

• RICERCA DI SPAZIO PER INSERIRE UN CONTRATTO (vedere 7.8)

6) Chiusura della sessione di vendita.

7.1.4. Validazione

Una sessione di validazione si scompone nel modo seguente:

1) Identificazione della carta.

2) Verifica dei diagnostici:

• REGOLE DI SCRITTURA DEL FILE LISTEEVENEMENTSPECIAUX (vedere 7.9).

3) Validazione:

• Ricerca di una validazione di corrispondenza:

• Ricerca di un contratto da validare:

o GESTIONE DELLE PRIORITA’ DEI CONTRATTI (vedere 7.2);

o GESTIONE DELLA RICERCA DI UN TITOLO VALIDABILE (vedere 7.2.3).

4) Validare:

• RICERCA DI UNA POSIZIONE PER SCRIVERE UN DIAGNOSTICO (vedere 7.9) (op- zionale);

• REGOLE DI SCRITTURA DEL FILE LISTEEVENEMENTSPECIAUX (vedere 7.9).(opzionale).

5) Chiusura della sessione di validazione.

7.1.5. Consultazione

L’accesso ai dati della carta è libero in lettura. Si deve semplicemente analizzare il tipo di carta restituito dall’ATR e l’ambiente per determinare la mappatura.

7.2. Gestione della priorità dei contratti

Le priorità possono essere trattate:

1) per limitazione al momento della vendita (regole di distribuzione sull’apparecchio di ven- dita)

2) per indicazione al momento della vendita di una priorità esplicita scritta sulla carta (scrit- tura delle priorità sulla carta);

3) per ricerca da parte del validatore dei contratti localmente validi a un dato momento, completato eventualmente da altre regole (regole di validazione sul validatore) o dall'uti- lizzo di un dispositivo di selezione da parte del cliente.

Sulla stessa rete di interoperabilità, lo stesso modo di utilizzare le regole di priorità scritte sulla carta deve essere applicato da tutti.

Le tappe logiche 1 & 3 devono essere definite per ogni progetto. E’ indispensabile che esista- no regole commerciali, perché è impossibile che un algoritmo assuma tutte le scelte possibili dei clienti.

A proposito delle priorità esplicite scritte sulla carta (tappa logica 2), è stata definita una solu- zione per rispondere alla necessità di avere soltanto un titolo validabile nello stesso tempo e luogo. Questa soluzione è la definizione della nozione di priorità dei contratti. Essa è definita a livello del file BestContract. Questa gestione si può riassumere come segue:

Su ogni rete, i contratti sono classificati per categoria alla creazione del prodotto (categoria 8, 9, A o B).

A ciascun contratto è associato un Provider (rete di accettazione) unico. Questo provider può essere sia un operatore sia un gruppo di operatori (che ad esemppio raggruppano tutti gli ope- ratori della rete (valore 0)).

Per una medesima categoria e un medesimo provider, la gerarchia dell’utilizzo dei contratti è governata da regole di priorità definite per la rete.

Le categorie sono in numero di 4 e ciascuna corrisponde a un livello di priorità differente.

L’ordine di priorità del trattamento (nel caso nominale) alla validazione si ottiene partendo dalla categoria di priorità maggiore (valore 8) fino a quella minore (valore B). Esistono mec- canismi di selezioni (descritti nel paragrafo seguente) che permettono inoltre di forzare la priorità di determinati contratti che appartengono a categorie di priorità inferiore utilizzando i valori di priorità da 0 a 7.

All’interno della stessa categoria e per un Provider unico, i contratti sono ordinati in rapporto alla loro posizione, e il primo della lista è quello con la priorità maggiore.

All’interno di una medesima categoria, si preparano tante liste ordinate quante ne esistono di provider differenti. Nell’esempio qui sotto, si può estrarre dalla categoria due liste di contratti (una per il’operatore P1 e l’altra per l’operatore P2). Il provider può allora decidere alla vali- dazione di privilegiare sia i contratti di P1 che quelli di P2 sia eventualmente di escludere del tutto i contratti di P1 o di P2.

La priorità è quindi definita alla vendita e applicata alla validazione.

Una rete, composta da n operatori, definisce regole comuni che amministrano la priorità dei contratti detti comuni. Inoltre, ciascun operatore può definire per i suoi contratti specifici le sue proprie regole di priorità senza perturbare le altre.

Ogni operatore può quindi avere una visione ristretta della lista per i soli contratti che egli è in grado di trattare alla validazione.

Trattamento alla validazione:

Scorrendo le categorie in ordine decrescente di priorità, dopo aver escluso i contratti di Pro- vider non gestiti, il miglior contratto è quindi:

1) il contratto in prima posizione se c’è soltanto un provider presente nella categoria

2) il contratto in prima posizione per il provider con maggiore priorità.

ESEMPIO DI APPLICAZIONE 1 La priorità è completamente stabilita alla distribuzione.

Ogni attore della rete può stabilire la definizione di un insieme di contratti detti comuni, e di- spone inoltre di un insieme di contratti che sono propriamente suoi, dei quali può modificare soltanto la priorità tra di loro e verso i contratti comuni.

Regole di utilizzo per la rete:

I contratti comuni (designati con Ci) sono classificati nelle categorie di livello di priorità 9. Ciascun operatore conosce le regole di priorità di questi contratti tra di loro e verso i propri contratti (designati con P1i per l’operatore P1).

La ricarica (vendita):

P11 P21

Priorità decrescente

L’operatore P1 carica un contratto P13 che considera più prioritario dei contratti comuni ma meno prioritario del suo contratto P11, pertanto lo posiziona nella prima categoria e nella prima posizione libera dopo il contratto P11. Si noti che P1 non è obbligato a tenere conto del contratto di P2.

La validazione:

Priorità decrescente

Elenco per l’apparecchiatura di validazione dell’operatore P1

66/93

Elenco per l’apparecchiatura di validazione dell’operatore P2

7.2.1. Meccanismo di selezione di un contratto

Come si è precedentemente definito, ciascun contratto appartiene a una categoria più o me- no prioritaria. Per permettere di forzare l’utilizzo di un contratto in un determinato istante e quindi per renderlo più prioritario rispetto ad altri, è necessario realizzare un meccanismo di selezione.

Gli stati stabili rappresentano i valori che prendono, per default, i diversi tipi di prodotti al momento della loro vendita. Gli stati instabili rappresentano la selezione volontaria del clien- te.

Si parla di gestione delle priorità assolute perché essa dipende dall’attribuzione predefinita di priorità a un tipo di contratto. “Priorità assolute” in opposizione a “priorità relative”, dove la priorità dei contratti viene ricalcolata a ciascuna riassegnazione di una priorità a un contratto in funzione degli altri titoli già contenuti nella carta.

Al momento della validazione, la priorità di un biglietto andata-ritorno passa per esempio da 3 a 7 (a meno che il contratto non diventi cancellabile, nel qual caso il valore è F).

Categoria “8”	Categoria “9”	Categoria “A”	Categoria “B”
‘0’h	‘1’h	‘2’h	‘3’h	Priorità “immediata”
‘4’h	‘5’h	‘6’h	‘7’h	Priorità “ritorno”
‘8’h	‘9’h	‘A’h	‘B’h	Priorità di default

Priorità particolari	Tipi
‘C’h	Priorità di default di un contratto non validabile (con particolari diritti)
‘D’h	Non definito
‘E’h	Priorità dei contratti non più validabili ma non cancellabili (contenenti un valore residuo)
‘F’h	priorità dei contratti cancellabili (contatto consumato x xxxxxxx)

Esempi di Gestione delle Priorità in un ambiente senza selezione possibile di titoli da valida- re e in cui il biglietto è a utilizzo immediato:

• al momento della vendita di un abbonamento, la priorità associata è ‘8’;

• al momento della vendita di un carnet di biglietti, la priorità associata è ‘9’. Pertanto non sarà utilizzabile che quando l’abbonamento non sarà più valido;

• al momento di una vendita di un biglietto andata-ritorno, la priorità ad esso associata è ‘3’. Questa priorità corrisponde al fatto che il titolo deve essere validato al prossimo passaggio al validatore. Al momento del passaggio al validatore (andata), la priorità del contratto passa a ‘7’. E’ ancora questo titolo che sarà validato al secondo pas- saggio. Al momento del secondo passaggio, la parte “ritorno” del biglietto sarà valida- ta e la sua priorità passerà a ‘F’;

• al momento della vendita di un biglietto andata semplice, la priorità ad esso associata è ‘3’. Questa priorità corrisponde al fatto che il titolo deve essere validato al prossimo passaggio al validatore (regola di distribuzione enunciata più sopra). al momento del passaggio al validatore, la priorità del contratto passa a ‘F’;

• quando un contratto non è più validabile ma conserva un valore residuo (caso di bi- glietto aperto esaurito ma non utilizzato), la priorità è ‘E’;

• al momento della scrittura di un diritto sulla carta, la priorità che gli si associa è ‘C’. (un contratto di priorità ‘C’ non è validabile);

• al momento in cui un contratto è consumato esaurito e/o è cancellabile, la priorità di- venta ‘F’.

Esempio di gestione di priorità in un ambiente dove l’utente ha la possibilità di selezionare un titolo da validare.

Il cliente possiede sulla sua carta un Abbonamento Settimanale di Lavoro (AHT). Ha anche sulla stessa carta un carnet di biglietti che gli permettono di andare a trovare la sua amica nel weekend. Pertanto, il venerdì sera, prima di prendere il treno, seleziona il carnet su un’apparecchiatura (cassa, validatore, colonnina) e con la stessa operazione lo valida: La priorità di questo contratto passa quindi a 1 e immediatamente dopo a ‘5’: diventando priori- taria rispetto al suo abbonamento.

Tabella di evoluzione dei valori di priorità nell’esempio precedente:

	Priorità dell’abbona mento AHT	Priorità del carnet di biglietti	Note
Prima della prima selezione al vali- datore	8	9	Priorità permanenti
Dopo la prima selezione al validatore	8	1	Il carnet all’abbonamento	è	prioritario	rispetto
Dopo la prima validazione al valida- tore	8	5	Il carnet all’abbonamento	è	prioritario	rispetto
Dopo la seconda validazione al vali- datore	8	9	Solo l’AHT è validabile

7.2.2. Principio generale di aggiornamento allo stato “cancellabile” di un contratto

Un contratto viene impostato sullo stato cancellabile quando soddisfa una delle seguenti con- dizioni:

• non permette più di viaggiare;

• non è più rimborsabile o scambiabile (anche con riduzioni);

• non permette più l’acquisto di titoli di trasporto a una tariffa privilegiata.

Questa operazione avviene al momento di un'operazione di vendita, ma si può ugualmente approfittare della lettura dei titoli al momento di una validazione per aggiornare se necessario lo stato dei contratti.

7.2.3. Esempio di ricerca di un titolo validabile

Si cerca in ListeContrat il o i contratti validabili, accettabili dal provider, non ancora esaminati a partire dalla priorità più alta.

In caso di contratti che hanno la stessa priorità, si prende tra essi il contratto che ha il minor rango in ListeContrat.

ESEMPIO il primo contratto da leggere è il quinto dell'elenco (Contratto 6 della carta). - Il 5 (Contratto 6) e il 6 (Contratto 7) hanno priorità maggiore e il 5 è davanti al 6.

Nbr	N. registrazione	1	2	3	4	5	6	7	8
8	Bitmap BestContract BestContractNetworkId	‘110’b R	‘110’b R	‘110’b R	‘110’b R	‘110’b R	110’b R	110’b R	N.R.
	BestContractTariff	‘0 10 6’	‘0 12 C’	‘1 12 6’	‘2 10 9’	‘2 05 2’	‘2 05 2’	‘2 05 F’
	BestContractPointer	‘2’	‘4’	‘5’	‘3’	‘6’	‘7’	‘8’

R : Referenziato

NR : non aggiornato

7.3. Regole di sostituzione di un contratto cancellabile

E’ possibile sostituire un contratto con un altro se:

• Il contratto da sostituire è nello stato cancellabile (Priorità del contratto: vedere 7.2.2);

• tutti gli eventi di validazione relativi al contratto sono posteriori alle 24 ore (trascorso questo ritardo, il titolo validato non ha più valore residuo). Regola adottata da alcuni operatori di trasporto Europei;

• tutti i diagnostici relativi a questo contratto sono estinti.

7.4. Soppressione di un contratto

Azione	Descrizione
Soppressione nel file elenco contratti senza conservazione dello sto- rico	Sia T il numero di registrazione nell'elenco contratti che punta verso la posizione del contratto da sopprimere Scalare tutte le registrazioni dell’elenco contratti di una registrazione a partire dalla registrazione T+1

Soppressione nel file elenco contratti con con- servazione dello storico (utilizzato in caso di un rinnovo di titolo forfetta- rio ad esempio) Sia T il numero di registrazione nell'elenco contratti che punta verso la posizione del contratto da sopprimere Mettere la priorità del contratto a Cancellabile nel file elenco contratti

ESEMPIO 1 Soppressione del contratto n. 5 con conservazione dello storico

	Nbr	N. registrazione	1	2	3	4	5	6	7	8
P R I M A	8	Bitmap BestContract BestContractNetworkId	‘110’b R	‘110’b R	‘110’b R	‘110’b R	‘110’b R	110’b R	110’b R	110’b R
		BestContractTariff	‘0 10 6’	‘0 12 C’’	‘1 12 6’’	‘2 10 9’’	‘2 05 F’	‘2 05 F’	‘2 05 F’	‘2 05 F’
		BestContractPointer	‘2’	‘4’	‘5’	‘3’	‘6’	‘7’	‘8’	‘1’
D O P O	8	Bitmap BestContract BestContractNetworkId	‘110’b R	‘110’b R	‘110’b R	‘‘110’b R	110’b R	110’b R	110’b R	110’b R
		BestContractTariff	‘0 10 6’	‘0 12 C’	‘1 12 F’	‘2 10 9’’	‘2 05 F’	‘2 05 F’	‘2 05 F’	‘2 05 F’
		BestContractPointer	‘2’	‘4	‘5’	‘3’	‘6’	‘7’	‘8’	‘1’

R : Referenziato

ESEMPIO 2 Soppressione del contratto n.5 senza conservazione dello storico

	Nbr	N. registrazione	1	2	3	4	5	6	7	8
P R I M A	8	Bitmap BestContract BestContractNetworkId	‘110’b R	‘110’b R	‘110’b R	‘110’b R	‘110’b R	110’b R	110’b R	110’b R
		BestContractTariff	‘0 10 6’	‘0 12 C’	‘1 12 6’’	‘2 10 9’’	‘2 05 F’	‘2 05 F’	‘2 05 F’	‘2 05 F’
		BestContractPointer	‘2’	‘4’	‘5’	‘3’	‘6’	‘7’	‘8’	‘1’
D O P O	7	Bitmap BestContract BestContractNetworkId	‘110’b R	‘110’b R	‘110’b R	‘110’b R	110’b R	110’b R	110’b R	NR
		BestContractTariff	‘0 10 6’	‘0 12 C’	‘2 10 9’’	‘2 05 F’	‘2 05 F’	‘2 05 F’	‘2 05 F’
		BestContractPointer	‘2’	‘4	‘3’	‘6’	‘7’	‘8’	‘1’

R : Referenziato NR : non aggiornato

7.5. Principi generali di sicurezza

Lato carta:

Le carte di trasporto funzionano sul principio di una separazione delle condizioni di accesso in funzione della tappa del ciclo di vita della carta. Pertanto vengono definite dall'applicazione di

trasporto DOFOCO tre chiavi di sicurezza che devono essere condivise totalmente o parzial- mente per l'interoperabilità.

• chiave di personalizzazione;

• chiave di distribuzione;

• chiave di validazione.

Ciascun file dell’applicazione si vede attribuire alcuni diritti in funzione della chiave. Il file che contiene le informazioni sull’ambiente e il titolare non può essere scritto che attraverso la chia- ve di personalizzazione. Il file dei contratti può a sua volta essere scritto attraverso la chiave di distribuzione. Il file del giornale trasporti dove vengono scritti gli eventi di validazione è acces- sibile attraverso la chiave di validazione (così come il file degli eventi speciali).

E’ ugualmente possibile utilizzare sulla carta contatori che possono essere incrementati attra- verso la chiave di distribuzione e decrementati attraverso la chiave di validazione.

Lato apparecchiatura:

L’apparecchiatura di validazione deve poter distinguere un titolo autentico da uno contraffatto allo scopo di autorizzare l’accesso alla rete soltanto a quelli autentici.

La ricarica permette di aumentare il valore del contenuto della carta. Il trasportatore deve dun- que proteggersi dalle ricariche non autorizzate. A questo scopo, la carta deve distinguere un terminale di ricarica autentico da uno contraffatto.

L’apparecchiatura di personalizzazione permette di inizializzare l’applicazione trasporto e di definire alcuni diritti dell’utente.

La soluzione adottata dai sistemi di bigliettazione allo scopo di realizzare queste autenticazioni consiste nell’utilizzare informazioni segrete, dette chiavi segrete, conosciute soltanto dai ter- minali e dalle carte. Questi dati riservati sono utilizzati per autenticare vicendevolmente appa- recchiature e carte.

Le chiavi segrete devono essere inaccessibili a tutti i truffatori allo scopo di impedire la crea- zione di falsi titoli di trasporto. Si otiene questo memorizzandole sulla scheda magnetica e dentro il modulo di sicurezza (SAM) in una zona di memoria inaccessibile all’esterno.

La carta possiede le tre chiavi che sono diversificate per ragioni di sicurezza. Il terminale pos- siede soltanto la chiave o le chiavi necessarie all’esecuzione della sua o delle sue funzioni.

Si possono allora distinguere tre famiglie di SAM: i Xxx di validazione, i SAM di distribuzione e i SAM di personalizzazione che contengono ciascuno un sottoinsieme delle tre chiavi.

Le operazioni effettuate da un SAM di validazione si riferiscono alla consumazione di un con- tratto, le operazioni fatte da un SAM di distribuzione si riferiscono alla creazione di un contrat- to. Cionondimeno e per deroga temporanea, è ammesso effettuare operazioni di validazione con la chiave di distribuzione se la dimensione e il numero dei contatori di maschera è insuffi- ciente. In questo caso, si devono prendere precauzioni supplementari di sicurezza per blocca- re il SAM di distribuzione.

7.6. Vincoli di sicurezza legati all’utilizzo di un contratto a contatore fisico

Il file “Contratti a contatori fisici” ha una protezione particolare: è il solo che può essere to- talmente modificabile da un apparecchio di distribuzione e parzialmente da un apparecchio di validazione. E’ in effetti possibile, se si dispone dei dati segreti di un apparecchio di distri-

xxxxxxx, modificare completamente (tramite UPDATE RECORD) una registrazione di "Con- tratti a contatori fisici”. Si procede così anche per inserire sulla carta un nuovo contratto. Un apparecchio che possiede le chiavi segrete di validazione non può effettuare altro che ag- giornamenti particolari: effettua degli “OR Logici” (tramite WRITE RECORD) sui dati del con- tratto, che corrispondono al passaggio dei bit 0 a 1. L’operazione inversa è impossibile. Que- sto modo di operare è utilizzato per permettere a un validatore di effettuare l’aggiornamento di un contratto, senza poter creare valore di bigliettazione. La gestione di alcuni dati come ContractStatus è completamente dipendente da questo principio e i valori crescenti in funzio- ne della vita del contratto proposti nel paragrafo 5.1 ne tengono conto.

Il campo ContractValidityJorneys, o ContractDataValidityJourneys, o ContractDataSoldX, se presente, indica il numero di viaggi autorizzato dal contratto. Per proteggere questo campo contro qualsiasi rischio di frode, è necessario che il validatore abbia il diritto per il solo de- cremento di questo numero. Per fare questo, si impiega il metodo seguente:

• Il campo ContractValidityJourneys, o ContractDataValidityJourneys o ContractData- SoldX è memorizzato in un file logico Contatore legato al contratto. Questo contatore necessita di diritti particolari per essere incrementato o decrementato: la chiave di di- stribuzione per la carica iniziale del contatore (a partire dal valore di ContractValidi- tyJourneys, o ContractDataValidityJourneys o ContractDataSoldX) o l’incremento del contatore che non è utilizzato; e la chiave di validazione per il decremento del conta- tore;

• i valori possibili del campo ContractValidityJourneys, o ContractDataValidityJourneys o ContractDataSoldX sono organizzati per venire decrementati a ogni consumazione. Una volta caricato il valore del campo al momento della creazione del contratto grazie alla chiave di distribuzione, esso non viene più modificato a livello del file Contratti. Questo funzionamento permette di avvalersi della chiave di distribuzione su un'appa- recchiatura di validazione. Solo il valore corrispondente del Contatore viene decre- mentato a ciascuna validazione;

• i validatori possono soltanto consumare diritti e non crearli.

I contatori da 1 a 4 sono collegati rispettivamente ai contratti da 1 a 4 per ciascuna carta. Al- cune carte possiedono meno contatori che contratti, e si parla allora di contratti impliciti (con contatore) ed espliciti (senza contatore). Per ottimizzare la gestione dei contratti, si cercherà di mettere i titoli che non necessitano di contatore nei contratti espliciti, in questo modo si po- tranno utilizzare i contratti impliciti senza utilizzare il contatore associato se per combinazio- ne tutte le posizioni esplicite sono utilizzate.

7.7. Regole di scrittura del file BestContracts

Azione

Descrizione

Scrittura di BestContracts

Il file BestContracts è completo? (numero di registrazione = massimo dei contratti che la carta può contenere) Sì – Si considera l’elenco degli y-1 contratti da conservare, al quale si aggiunge in ultima posizione la nuova registrazione. No – si cerca la prima registrazione dell’elenco contratti disponibile (mai utilizzata) dopo l’ultima Inserimento della nuova registrazione nella locazione trovata

I contratti devono essere posizionati in modo consecutivo all’interno dell’Elenco Contratti. Se il bitmap corrispondente a un contratto (Bitmap BestContract) indica l’assenza di un contratto di questo rango, si considera che non ci sono più contratti descritti nella lista contratti dopo di quello, e questo qualsiasi sia la posizione di questo contratto. D’altra parte il campo BestCon- tracts dell’elenco contratti indica il numero effettivo di contratti sulla carta. Deve pertanto es- sere aggiornato contemporaneamente all'elenco Contratti.

ESEMPIO 1 Con una carta limitata a 8 contratti:

Elenco contratti completo: Il nuovo contratto deve inserirsi nel contratto ‘5’ e in posizione ‘8’ del file ListContrat (vedere 7.8)

	Nbr	N. registrazione	1	2	3	4	5	6	7	8
P R I M A	8	Bitmap BestContract BestContractNetworkId	‘110’b R	‘110’b R	‘110’b R	‘110’b R	‘110’b R	110’b R	110’b R	110’b R
		BestContractTariff	‘0 10 6’	‘0 12 C’	‘1 12 F’	‘2 10 9’	‘2 05 F’	‘2 05 F’	‘2 05 F’	‘2 05 F’
		BestContractPointer	‘1’	‘2’	‘5’	‘3’	‘6’	‘7’	‘8’	‘4’
D O P O	8	Bitmap BestContract BestContractNetworkId	‘110’b R	‘110’b R	‘110’b R	‘110’b R	‘110’b R	‘110’b R	‘110’b R	‘110’b R
		BestContractTariff	‘0 10 6’	‘0 12 C’’	‘2 10 9’	‘2 05 F’’	‘2 05 F’’	‘2 05 F’	‘2 05 F’	‘2 05 6’
		BestContractPointer	‘1’	‘2’	‘3’	‘6’	‘7’	‘8’	‘4’	‘5’

R : Referenziato

ESEMPIO 2 Con una carta limitata a 4 contratti con contatore:

Elenco contratti non completo

	Nbr	N. registrazione	1	2	3	4
P R I M A	3	Bitmap BestContract	‘110’b	‘110’b	‘110’b	NR
		BestContractNetworkId	R	R	R
		BestContractTariff	‘0 10 6’	‘2 10 9’	‘2 05 F’
		BestContractPointer	‘1’	‘2’	‘3’
D O P O	4	Bitmap BestContract BestContractNetworkId	‘110’b R	110’b R	‘110’b R	110’b R
		BestContractTariff	‘0 10 6’	‘2 10 9’	‘2 05 F’	‘2 05 6’
		BestContractPointer	‘1’	‘2’	‘3’	‘4’

R : Referenziato NR: non aggiornato

Questo meccanismo permette di garantire che il rinnovo di un contratto si trovi inserito nell’elenco Contratti dopo il contratto rinnovato. Poichè Il validatore legge il primo contratto della lista a parità di priorità, viene ottimizzato il tempo di validazione.

La posizione 1 corrisponde quindi al contratto più anziano e la 8 o 4 a seconda della carta corrispondono al più recente.

7.8. Ricerca di spazio per inserire un contratto

Ora verrà mostrato come cercare una posizione con o senza contatore a seconda del tipo di contratto. (vedere 7.7)

Azione	Descrizione
Contratto che necessi- ta un contatore (car- net di biglietti ad esempio)	Tutti i contratti con contatore sono puntati in BestContract? No - Prendere la posizione Contract trovata e aggiungere alla fine dell’elenco il nuovo BestContract Sì – Cercare il contratto più anziano con contatore dell'elenco avente: ⎯ una priorità cancellabile ‘F’ in BestContractTariff ⎯ nessun evento di validazione a lui collegato nel Giornale dei trasporti e avvenuto da meno di X ore ⎯ nessun diagnostico attivo E' stata trovata una posizione? Sì – Prendere la posizione Contract determinata e aggiungere al termine dell’elenco il BestContract rispettando le regole di scrittura descritte più avanti No – Non c’è spazio disponibile (carta satura)
Contratto che non ne- cessita di contatore (abbonamento illimita- to)	Tutti i contratti senza contatore sono puntati in BestContract? No - Prendere la posizione Contract trovata e aggiungere alla fine dell’elenco il nuovo BestContract Sì – Cercare il contratto più anziano senza contatore dell'elenco avente: ⎯ una priorità cancellabile ‘F’ in BestContractTariff ⎯ nessun evento di validazione a lui collegato nel Giornale dei trasporti e avvenuto da meno di X ore ⎯ nessun diagnostico attivo E' stata trovata una posizione? Sì – Prendere la posizione Contract determinata e aggiungere al termine dell’elenco il BestContract rispettando le regole di scrittura descritte più avanti No – Cercare un contratto che necessita di contatore

ESEMPIO Con una carta limitata a 8 contratti (4 contratti con contatore e altri 4 contratti senza contatore):

1) Elenco contratti completo e ricerca di una posizione senza contatore:

Il nuovo contratto deve inserirsi nel contratto ‘5’ e in posizione ‘8’ del file BestContract

	Nbr	N. registrazione	1	2	3	4	5	6	7	8
P R I M A	8	Bitmap BestContract BestContractNetworkId	‘110’b R	‘110’b R	‘110’b R	‘110’b R	‘110’b R	110’b R	110’b R	110’b R
		BestContractTariff	‘0 10 6’	‘0 12 C’	‘1 12 F’	‘2 10 9’	‘2 05 F’	‘2 05 F’	‘2 05 F’	‘2 05 F’
		BestContractPointer	‘1’	‘2’	‘5’	‘3’	‘6’	‘7’	‘8’	‘4’

D O P O	8	Bitmap BestContract BestContractNetworkId	‘110’b R	‘110’b R	‘110’b R	‘110’b R	110’b R	110’b R	110’b R	110’b R
		BestContractTariff	‘0 10 6’	‘0 12 C’	‘2 10 9’	‘2 05 F’	‘2 05 F’	‘2 05 F’	‘2 05 F’	‘2 05 6’
		BestContractPointer	‘1’	‘2’	‘3’	‘6’	‘7’	‘8’	‘4’	‘5’

R : Referenziato

2) Elenco contratti non completo e ricerca di una posizione senza contatore:

Il nuovo contratto deve inserirsi nel contratto ‘6’ e in posizione ‘7’ del file BestContract

	Nbr	N. registrazione	1	2	3	4	5	6	7	8
P R I M A	7	Bitmap BestContract BestContractNetworkId	‘110’b R	‘110’b R	‘110’b R	‘110’b R	‘110’b R	110’b R	110’b R	N.R.
		BestContractTariff	‘0 10 6’	‘0 12 C’	‘1 12 6’	‘2 10 9’	‘2 05 F’	‘2 05 F’	‘2 05 F’
		BestContractPointer	‘1’	‘2’	‘5’	‘3’	‘6’	‘7’	‘8’
D O P O	7	Bitmap BestContract BestContractNetworkId	‘110’b R	‘110’b R	‘110’b R	‘110’b R	110’b R	110’b R	110’b R
		BestContractTariff	‘0 10 6’	‘0 12 C’	‘1 12 6’	‘2 10 9’	‘2 05 F’	‘2 05 F’	‘2 05 6’
		BestContractPointer	‘1’	‘2’	‘5’	‘3’	‘7’	‘8’	‘6’

R : Referenziato NR: non aggiornato

3) Elenco contratti non completo e ricerca di una posizione senza contatore:

Il nuovo contratto si inserisce nel contratto ‘4’ (che può contenere normalmente un contatore ma che non verrà utilizzato) nella posizione ‘8' del file BestContract

	Nbr	N. registrazione	1	2	3	4	5	6	7	8
P R I M A	7	Bitmap BestContract BestContractNetworkId	‘110’b R	‘110’b R	‘110’b R	‘110’b R	‘110’b R	110’b R	110’b R	N.R.
		BestContractTariff	‘0 10 6’	‘0 12 C’	‘1 12 6’	‘2 10 9’	‘2 05 C’	‘2 05 6’	‘2 05 6’
		BestContractPointer	‘1’	‘2’	‘5’	‘3’	‘6’	‘7’	‘8’
D O P O	8	Bitmap BestContract BestContractNetworkId	‘110’b R	‘110’b R	‘110’b R	‘110’b R	‘110’b R	110’b R	110’b R	‘110’b R
		BestContractTariff	‘0 10 6’	‘0 12 C’	‘1 12 6’	‘2 10 9’	‘2 05 C’	‘2 05 6’	‘2 05 6’	‘2 05 C’
		BestContractPointer	‘1’	‘2’	‘5’	‘3’	‘6’	‘7’	‘8’	‘4’

7.9. Ricerca di una posizione per inserire un diagnostico

Il livello di severità del diagnostico è indicato nel campo SpecialEventSeriousness della struttura SpecialEvents ListeEvenementsSpeciaux. Un diagnostico (o evento speciale) si di- ce “attivo” se la sua SpecialEventSeriousness è diversa da zero. Si dice “estinto” in caso contrario. Si dice “bloccante” se la sua SpecialEventSeriousness è maggiore di 1.

Azione

Descrizione

Ricerca di una posi- zione per inserire un diagnostico

Tutti i diagnostici sono puntati in SpecialEvents (ListeEvenementsSpeciaux)? No - Prendere la posizione SpecialEvent trovata e aggiungere alla fine dell’elenco il nuovo SpecialEvent Sì – Cercare lo SpecialEvent più anziano dell’elenco SpecialEvents avente: ⎯ la SpecialEventSeriousness di livello inferiore o uguale a quello da inserire ⎯ lo SpecialEventProvider del diagnostico da inserire E' stata trovata una posizione? Sì – Prendere la posizione SpecialEvent determinata e aggiungere al termine dell’elenco lo SpecialEvent rispettando le regole di scrittura descritte più avanti No – non c’è spazio disponibile (normalmente impossibile)

Regole di scrittura del file ListeEvenementSpeciaux (SpecialEvents)

Il meccanismo è identico a quello utilizzato nella gestione di BestContracts.

Gli Eventi Speciali devono essere posizionati consecutivamente all’interno dell'Elenco degli Eventi Speciali. Se il bitmap corrispondente a un Evento Speciale (Bitmap SpecialEvent) in- dica l’assenza di Eventi Speciali di questo rango, si considera che non ci sono più Eventi Speciali descritti nell’Elenco degli Eventi Speciali dopo quello, e ciò qualsiasi sia la posizio- ne di questo Evento Speciale. D’altra parte, il campo SpecialEventNumber dell’elenco degli Eventi Speciali indica il numero effettivo di Eventi Speciali sulla carta: deve dunque essere aggiornato in contemporanea con l’elenco degli Eventi Speciali.

Azione

Descrizione

Scrittura sul file ListeEvénementsSpéciaux

Il file ListeEvenementSpeciaux è completo? (numero di registrazioni = massimo di x diagnostici che può contenere la carta) Sì – Si considera l’elenco degli x-1 eventi speciali da conservare, al quale si aggiunge in ultima posizione la nuova registrazione. No – Ricerca la prima registrazione di ListeEvenementSpeciaux disponibile (all’inizio la più anziana) inserisce la nuova registrazione nella locazione trovata

ESEMPIO Con una carta che puà gestire 3 eventi:

1) ListeEvenementSpeciaux completa: Il nuovo diagnostico si inserisce nell’evento ‘2’ in posizione ‘3’ del file ListeEvenementSpeciaux

	Nbr	N. registrazione	1	2	3
P R I M A	3	Bitmap SpecialEvent	‘1110’b	‘1110’b	‘1110’b
		SpecialEventNetworkId	R	R	R
		SpecialEventProvider	‘03’	‘02’	‘01’
		SpecialEventSeriousness	‘1’	‘0’	‘2’
D O P O	3	Bitmap SpecialEvent	‘1110’b	‘1110’b	‘1110’b
		SpecialEventNetworkId	R	R	R
		SpecialEventProvider	‘03’	‘01’	‘02’
		SpecialEventSeriousness	‘1’	‘2’	‘1’
		SpecialEventPointer	‘1’	‘3’	‘2’

NU: Non utilizzato per l’interoperabilità NR: non aggiornato

2) ListeEvenementSpeciaux non è interamente aggiornata: il nuovo dagnostico deve inse- rirsi nell’evento ‘2’ in posizione ‘3’ del file ListeEvenementSpeciaux

	Nbr	N. registrazione	1	2	3
P R I M A	2	Bitmap SpecialEvent SpecialEventNetworkId SpecialEventProvider SpecialEventSeriousness SpecialEventPointer	‘1110’b R ‘02’ ‘1’ ‘1’	‘1110’b R ‘03’ ‘2’ ‘3’	NR
D O P O	3	Bitmap SpecialEvent SpecialEventNetworkId SpecialEventProvider SpecialEventSeriousness SpecialEventPointer	‘1110’b R ‘02’ ‘1’ ‘1’	‘1110’b R ‘03’ ‘2’ ‘3’	‘1110’b R ‘01’ ‘1’ ‘2’

R : Referenziato NR: non aggiornato

8. Mappa delle carte esistenti utilizzate da ATM e TRENORD

Caratteristica delle carte della gamma Calypso:

• la dimensione fisica delle registrazioni è di 29 byte, il che rende necessario in alcuni casi il raggruppamento di più strutture in un’unica registrazione fisica allo scopo di limitare il numeto di letture e di scritture (es: file fisico “ambiente/trasportatore”);

• essendo l’accesso ai dati in modifica soggetto all’utilizzo delle chiavi, conviene ugualmente raggruppare per file i dati che necessitano lo stesso livello di sicurezza e quindi lo stesso tipo di chiavi.

• ci sono meccanismi (gestione delle priorità, vedere 7.2) che permettono di ottimizzare i tempi di trattamento durante le fasi critiche di gestione della carta (validazione)

8.1. La Carta di Trasporto 97 Struttura 2

La descrizione fisica di questa carta differisce leggermente dalla sua descrizione logica:

• Le strutture Environment e Porteur (Titolare) sono raggruppate su di un unico file fisico ('$2001’) che contiene una struttura Enviromnent seguita da una struttura Holder:

o la somma delle dimensioni di queste due strutture non deve superare quella di una registrazione del file (1 registrazione di 29 byte equivale a 232 bit);

o al momento della modifica di una di queste due strutture, si deve riscrivere una regi- strazione completa nel file, dove vengono riportati i valori della struttura che non è cambiata.

• Le strutture Journaltransport e ListeEvenementSpeciaux sono raggruppate in un unico file ciclico (‘$2010’) di 6 registrazioni (6 registrazioni di 29 byte sono 6 volte 232 bit). Ogni registrazione di questo file ciclico contiene una struttura Event seguita da una struttura

SpecialEvents:

o la somma delle dimensioni di queste due strutture non deve superare quella di una registrazione del file (1 registrazione di 29 byte equivale a 232 bit);

o al momento della modifica di una di queste due strutture, si deve riscrivere una regi- strazione completa nel file, dove vengono riportati i valori della struttura che non è cambiata. Se le due strutture sono state modificate, le si registra entrambe in una volta sola.

• La struttura EventiSpeciali è memorizzata in un file lineare (‘$2040’) di 3 registrazioni di dimensione fissa (3 registrazioni di 29 byte corrispondenti a 3 volte 232 bit) che permettono di memorizzare 3 eventi speciali.

• La struttura ListeContrats si trova nel file fisico (‘$2050’) che contiene una struttura Best- Contracts (1 registrazione di 29 byte corrisponde a 232 bit)

• La struttura Contratti è memorizzata in:

o un file lineare di 4 registrazioni di dimensione fissa 'Contratti' ($2020'): esso permet- te di memorizzare fino a 4 contratti (4 registrazioni di 29 byte corrispondenti a 4 vol- te 232 bit) dotate di un campo

o ContractValidityJourneys o ContractDataValidityJourneys o ContractDataSoldX ;

o quattro file ‘Contatore (da ‘$202A’ a ‘$202D’) che memorizzano i valori dei campi ContractValidityJourneys ou ContractDataValidityJourneys ou ContractDataSoldX legati ai contratti a contatore;

o un file lineare di 4 registrazioni di dimensione fissa 'Contratti 2' ($2030'); esso per- mette di memorizzare fino a 4 contratti (4 registrazioni di 29 byte corrispondenti a 4 volte 232 bit). Questi contratti non possono possedere il campo ContractValidi- tyJourneys o ContractDataValidityJourneys o ContractDataSoldX.

8.2. La Carta Trasporto 97 Struttura 3

L’organizzazione fisica di questa carta differisce leggermente dalla sua descrizione logica:

• Le strutture Environnement e Porteur (Titolare) sono raggruppate su di un unico file fisi- co ('$2001’) che contiene una struttura Enviromnent seguita da una struttura Holder:

o la somma delle dimensioni di queste due strutture non deve superare quella di una registrazione del file (1 registrazione di 29 byte equivale a 232 bit);

o al momento della modifica di una di queste due strutture, si deve riscrivere una re- gistrazione completa nel file, dove vengono riportati i valori della struttura che non è cambiata.

• Le strutture Journaltransport e ListeEvenementSpeciaux sono raggruppate in un unico file ciclico (‘$2010’) di 3 registrazioni (3 registrazioni di 29 byte sono 3 volte 232 bit). Ogni registrazione di questo file ciclico contiene una struttura Event seguita da una struttura SpecialEvents:

o la somma delle dimensioni di queste due strutture non deve superare quella di una registrazione del file (1 registrazione di 29 byte equivale a 232 bit);

o al momento della modifica di una di queste due strutture, si deve riscrivere una re- gistrazione completa nel file, dove vengono riportati i valori della struttura che non è cambiata. Se le due strutture sono state modificate, le si registra entrambe in una volta sola.

• La struttura EventiSpeciali è memorizzata in un file lineare (‘$2040’) di una registrazione di dimensione fissa (cioè 232 bit) che permette di memorizzare 2 eventi speciali.

• La struttura ListeContrats si trova nel file fisico (‘$2050’) che contiene una struttura Best- Contracts (1 registrazione di 29 byte corrisponde a 232 bit)

• La struttura Contratti è memorizzata in:

o un file lineare di 4 registrazioni di dimensione fissa 'Contratti' ($2020'): Esso per- mette di memorizzare fino a 4 contratti (4 registrazioni di 29 byte corrispondono a

4 volte 232 bit) dotate di un campo ContractValidityJourneys o ContractDataValidi- tyJourneys o ContractDataSoldX ;

o quattro file ‘Contatore (da ‘$202A’ a ‘$202D’) che memorizzano i valori dei campi ContractValidityJourneys o ContractDataValidityJourneys o ContractDataSoldX le- gati ai contratti a contatore;

o un file lineare di una registrazione di dimensione fissa 'Contratti 2' ($2030'): esso permette di memorizzare 1 contratto (cioè 232 bit). Questo contratto non può possedere il campo ContractValidityJourneys o ContractDataValidityJourneys o ContractDataSoldX.

8.3. La Carta GTM Light

La descrizione fisica di questa carta differisce leggermente dalla sua descrizione logica:

• Le strutture Environnement e Porteur (Titolare) sono raggruppate su di un unico file fisico ('$2001’) che contiene una struttura Enviromnent seguita da una struttura Holder:

• la somma delle dimensioni di queste due strutture non deve superare quella di una regi- strazione del file (1 registrazione di 29 byte equivale a 232 bit);

• al momento della modifica di una di queste due strutture, si deve riscrivere una registra- zione completa nel file, dove vengono riportati i valori della struttura che non è cambiata.

• Le strutture Journaltransport e ListeEvenementSpeciaux sono raggruppate in un uni- co file ciclico (‘$2010’) di 3 registrazioni (3 registrazioni di 29 byte sono 3 volte 232 bit). Ogni registrazione di questo file ciclico contiene una struttura Event seguita da una strut- tura SpecialEvents:

o la somma delle dimensioni di queste due strutture non deve superare quella di una registrazione del file (1 registrazione di 29 byte equivale a 232 bit);

o al momento della modifica di una di queste due strutture, si deve riscrivere una registrazione completa nel file, dove vengono riportati i valori della struttura che non è cambiata. Se le due strutture sono state modificate, le si registra entrambe in una volta sola.

• La struttura EventiSpeciali è memorizzata in un file lineare (‘$2040’) di una registrazio- ne di dimensione fissa (cioè 232 bit) che permette di memorizzare 2 eventi speciali.

o la struttura inserita successivamente a ListeContrats corrisponde al primo evento speciale;

o la prima struttura EvenementSpecial del file ‘2040’ corrisponde al secondo even- to speciale;

o la seconda struttura EvenementSpecial del file ‘2040’ corrisponde al terzo evento speciale;

o le strutture che codificano questi eventi speciali sono limitate a 116 bit.

• La struttura ListeContrats oltre a una struttura EvenementSpeciaux si trovano nel file fi- sico (‘$2050’ (referenziato $2030 o $2050)) che contiene una struttura BestContracts (1 registrazione di 29 byte corrisponde a 232 bit) e una strtuttura EvenementSpeciaux.

• La struttura Contratti è memorizzata in:

o un file lineare ‘Contrats’ (‘$2020’) di 4 registrazioni (4 registrazioni di dimensione fissa di 29 byte corrispondono a 4 volte 232 bit) che permettono di memorizzare fino a 4 contratti dotati di un campo ContractValidityJourneys o ContractDataVa- lidityJourneys o ContractDataSoldX ;

o quattro file ‘Contatore (da ‘$202A’ a ‘$202D’) che memorizzano i valori dei campi ContractValidityJourneys o ContractDataValidityJourneys o ContractDataSoldX legati ai contratti a contatore;

o la GTML possiede 5 contatori supplementari (da $202E a $2062)

8.4. La CT2000 Transcarte

L’organizzazione fisica di questa carta è conforme alla sua descrizione logica. La GTML possie- de 1 contatore supplementare ($2062)

8.5. Caratteristiche relative ai supporti previsti

I supporti previsti impongono di precisare alcuni elementi, che le applicazioni devono rispet- tare, contenuti su questi nuovi supporti a cui il presente documento può essere applicato. Il supporto può essere multiapplicativo, nel qual caso ciò riguarda solo la (le) applicazione(i) che cercano di essere compatibili. Si raccomanda che l’applicazione Intercode sia selezio- nata per default nel caso in cui l’applicazione presente non proceda a un SELECT APPLI- CATION come prima operazione.

Sistema di comando, sicurezza, protocolli di comunicazione: l’applicazione è conforme allo standard Calypso revisione 1 o 2. Essa può inoltre essere conforme allo standard Ca- lypso 3. L’applicazione può essere conforme allo standard Calypso 2 anche se la struttura di riferimento è stata alloggiata su una carta Calypso 1.

Struttura dei file: l’applicazione ha una struttura di file totalmente identica a una delle quat- tro strutture di riferimento descritte nei paragrafi da 8.1 a 8.4 del presente documento per gli aspetti identificativi dei file (Long Identifier LID e Short Identifier SID), dimensione dei file (numero di registrazioni e dimensione delle registrazioni) e condizioni di accesso dei file (comandi Calypso autorizzati e chiavi necessarie per questi comandi). Sono tuttavia tollera- te le seguenti differenze:

• la presenza di file supplementari è autorizzata per file senza significato funzionale (esempio: file che contengono l’identificativo dell’applicazione (AID), file che conten- gono le chiavi (Keys) ecc). Questi eventuali file supplementari non potranno tuttavia in alcun caso essere utilizzati per memorizzare elementi di dati applicativi (trasporto o al- tro);

• se uno solo degli EF di identificazione (LID/SID) 2030/06 o 2050/1E è presente nella struttura di riferimento, è permesso di accedere a questo stesso EF anche per l’altro identificativo, anche se non è il caso nella struttura di riferimento;

• e la struttura di riferimento integra soltanto 4 contatori individuali (caso della CD97-2 e CD97-3, i contatori che hanno gli identificativi da 202A/0A a 202D/0D), è permesso sostituirli con un file comune di 9 contatori (2069/19) e un’emulazione dei contatori in- dividuali. Questa emulazione può portare solo ai 4 primi contatori (identificativi da 202A/0A a 202D/0D) o sui 9 contatori (identificativi da 202A/0A a 202F/0F e da 2060/10 a 2062/12). L’utilizzo dei contatori non presenti nella struttura di riferimento per memorizzarvi elementi di dati applicativi (trasporto o altro) è pertanto proibito;

• le condizioni di accesso al file comune dei contatori possono autorizzare i comandi di incremento e di decremento, anche se nella struttura di riferimento questa gestione non è possibile che sui file individuali dei contatori (reali o emulati);

• il comando WRITE RECORD sotto controllo della chiave 3 è autorizzato sull’EF 2010/08 (Giornale dei Trasporti) anche se esso non si trova nella struttura di riferimen- to.

Crittografia utilizzata: l’applicazione può utilizzare tutta la crittografia autorizzata da Calyp- so, ad eccezione del caso particolare in cui essa è alloggiata su un supporto che non può essere distinto, in materia di protocollo di comunicazione e di ATR, da uno dei supporti di ri- ferimento descritti ai paragrafi da 8.1 a 8.4 (in altri termini: ad eccezione del caso di un sup- porto che dialoga con protocollo Innovatron e che ha una risposta alla messa in tensione (ATR) identica a quella di uno dei supporti di riferimento). In quest’ultimo caso, la crittografia deve essere la stessa di quella del supporto di riferimento (e, di conseguenza, il tipo di chia- vi deve essere ugualmente lo stesso di quello del supporto di riferimento: DES per le appli- cazioni di tipo CD97 e GTML, DES-X per le applicazioni di tipo DOFOCO).

Informazioni di Startup: l’applicazione è dotata di una “informazione di startup” conforme sotto tutti i punti alle esigenze Calypso (nota tecnica Calypso n.1) ad eccezione, in deroga, del caso particolare di un supporto che emula fortemente uno dei quattro supporti di riferi- mento descritti nei paragrafi da 8.1 a 8.4 (si veda qui di seguito la definizione di "emulazione forte"). In questo caso particolare, le “informazioni di startup” dell’applicazione e del suppor- to devono essere totalmente identiche alle informazioni di startup del supporto di riferimento che viene emulato.

Protocollo di comunicazione: Il protocollo di comunicazione è legato alla versione di Ca- lypso scelta per l’applicazione, indipendentemente dalla struttura dei file.

NOTA E’ opportuno verificare che il protocollo di comunicazione scelto sia compatibile con le apparecchiature installate nell’insieme dei partner, o di fare evolvere queste apparecchia- ture.

Riferimento	Protocolli
Calypso I	B Innovatron
Calypso II	B Innovatron o ISO/IEC 14443 Type X
Xxxxxxx XXX	XXX/XXX 00000 Type A, o ISO/IEC 14443 Type B, o B Innovatron

Nomenclatura: si definiscono i seguenti termini per identificare i supporti:

• Supporto storico: ciascuno dei quattro supporti definiti ai paragrafi da 8.1 a 8.4 del presente documento.

• Emulazione forte: tutti i nuovi supporti come definiti qui sotto, nei quali il protocollo è lo stesso di quello dei supporti storici (protocollo Innovatron),e nei quali la risposta alla messa sotto tensione (ATR) è totalmente identica a quella di un supporto storico di riferimento. In conformità alle esigenze del paragrafo 8.6, un tale supporto non deve allora ospitare che un’unica applicazione trasporto, avente una struttura di file identi- ca a quella del supporto storico di riferimento (a meno delle tolleranze descritte pre- cedentemente), chiavi dello stesso tipo di quelle del supporto storico di riferimento, e un insieme di comandi almeno identico all’insieme di comandi del supporto storico di riferimento (comandi supplementari che permettono di essere conformi a una revi- sione ulteriore di Calypso sono comunque autorizzati).

NOTA Un supporto in emulazione forte può, al di fuori delle esigenze esposte qui sopra, es- sere diverso dal supporto storico di riferimento, e in particolare può alloggiare applicazioni terze che non esistono sul supporto di riferimento, o al contrario non alloggiare applicazioni terze che esistono sul supporto storico di riferimento.

• Emulazione debole: tutti i nuovi supporti così come definiti qui sopra e che non sono in emulazione forte.

8.6. Nomenclatura delle applicazioni Intercode

Tutte le applicazioni Intercode conformi al presente documento e a una versione 2 o successiva dello standard Calypso, devono essere dotate di un identificativo (AID). La funzione di questo identificativo (AID) è di determinare rapidamente se esiste, su un supporto dato, un’applicazione Intercode associata a un dominio bigliettario ben preciso, e in questo caso di selezionarla diret- tamente. Inoltre:

• quando un supporto non integra l’applicazione richiesta, tentare la sua selezione per mez- zo dell’AID permette di sapere immediatamente che non è presente, e di conseguenza di non perdere tempo esaminando l'applicazione Intercode di un altro dominio bigliettario;

• quando un supporto integra svariate applicazioni Intercode, ciascuna associata a un domi- nio di bigliettazione particolare, effettuare la selezione dell’applicazione richiesta tramite il suo AID permette di selezionare immediatamente l’applicazione Intercode giusta, senza dover scorrere le varie applicazioni Intercode presenti per trovare quella pertinente.

• quando si esaminano supporti che integrano svariate applicazioni Intercode associate allo stesso dominio di bigliettazione, è possibile definire, all’interno di questo dominio di bigliet- tazione, valori differenti che permettono di distinguere tra queste applicazioni.

Un AID è composto di un RID di 5 bytes o (registrati ufficialmente secondo una procedura e un piano di numerazione definiti nella normativa ISO 7816-5) e di un PIX libero di 11 byte al massi- mo. La CN03 ha richiesto un RID che serva (fra l’altro) di base agli AID delle applicazioni che uti- lizzano Intercode, e ha definito per il PIX la struttura seguente:

• 5 bytes definiti dalla CN03;

• 6 bytes a disposizione di ciascun richiedente per le sue proprie necessità, in particolare per identificare applicazioni differenti nello stesso bacino di interoperabilità.

Ciascun utente del presente documento dovrà richiedere il RID e la prima parte del PIX alla CN03.

Distinzione tra i supporti conformi alla presente versione del documento e i supporti già distribuiti, conformi alle versioni precedenti: Allo scopo di permettere un trattamento ottima- le dei supporti nel periodo di convivenza tra i supporti conformi alla presente versione del docu- mento e quelli conformi alle versioni precedenti (vedere Appendice B per una descrizione di questo trattamento) è proibito rilasciare supporti che non possano essere distinti dai supporti di riferimento descritti ai paragrafi da 8.1 a 8.4 in termini di protocollo di comunicazione e di ATR (Answer To Reset = risposta alla messa sotto tensione), in quanto l’applicazione di bigliettazione Intercode in essi contenuta deve essere gestita diversamente da quella del supporto di riferi- mento corrispondente.

In altri termini: se un supporto dialoga con protocollo Innovatron e ha una risposta alla messa in tensione (ATR) identica a quella di uno dei supporti di riferimento descritti ai paragrafi da 8.1 a 8.4, allora questo supporto può contenere una sola applicazione Intercode, che deve poter esse- re gestita nello stesso modo che sul supporto di riferimento, in termini di insieme di comandi (versione applicabile dello standard Calypso), di struttura dei file e di tipo di chiavi utilizzate.

9. Smartcard a microprocessore previste per il sistema BELL

9.1.1. Introduzione

Nel seguente paragrafo vengono trattate le tipologie di smart card dotate di micropro- cessore o dispositivi equivalenti quali telefonini NFC, token o tag RFID compatibili. Le smartcard gestite saranno di tipo 3 (Calypso rev. 3.1) e seguiranno le indicazioni di struttura e sicurezza presentate nei precedenti capitoli.

Per motivi tecnici è opportuno che sia un soggetto unico a gestire tutti gli aspetti di dettaglio relativi alle smart card non esplicitamente trattati in questo documento (distribuzione smart card e SAM, gestione della firma per l’interoperabilità, valori attribuiti ai campi).

9.1.2. Protocolli di comunicazione delle carte a microprocessore

Il protocollo contactless dovrà essere conforme a quanto indicato dalla specifica ISO 14443 parte 3, le carte dovranno rispondere inviando il loro ATQB a tutti i comandi di REQB o WUPB inviati da un accoppiatore aventi il seguente valore del parametro AFI:

• AFI=00hex – nessuna preferenza, tutte le carte in campo devono rispondere.

La risposta ATQB che la carta dovrà inviare alla ricezione del comando di REQB o WUPB dovrà contenere i seguenti parametri relativi al protocollo (Protocol Info):

o Protocol Type e TR2, indica la tipologia di protocollo, il valori ammessi sono 1, 3, 5 e 7 che indica che il protocollo è pienamente conforme alle normative ISO 14443 compresa la parte 4;

o Max_Frame_Size, indica la lunghezza massima ammissibile di ogni pacchetto dati in trasmissione, saranno ammessi valori 07hex (frame di lunghezza 128byte) oppure 08hex (frame di lunghezza 256 byte);

o Bit_Rate_Capability, indica le velocità di protocollo ammesse dalla car- ta. L’accoppiatore ha facoltà di scegliere, in base ai valori dichiarati, velocità di bit rate superiori a quella di default, circa 106Kbps. Le velocità di trasfe- rimento (bit rate) ammesse sono indicate nella tabella riportata di seguito (tabella 7.9.4.6 delle ISO14443-3). I valori massimi ammissibili del parametro Bit_Rate_Capability saranno:

Bit_Rate_Capability=B3hex, fino a 424Kbps in entrambe le direzioni

9.1.3. Definizione dei requisiti fisici e meccanici delle carte a microprocessore

Le dimensioni fisiche delle carte dovranno essere conformi alle specifiche ISO 7816 Parte 1 in particolare il formato indicato con la sigla ID1 di dimensioni LxHxP 85,60mmvx53,98mmx0,76mm.

Il materiale costruttivo della carta dovrà essere di tipo plastico (PVC, PET o equivalenti), nel caso venga utilizzato un differente supporto fisico dovrà essere fornita opportuna garanzia sul- la qualità e sulla sua durata temporale. La rigidità meccanica dovrà essere conforme a quanto indicato nella stessa normativa.

Le carte dovranno essere conformi alle normative di resistenza allo stress meccanico (torsione, flessione) indicate dalle ISO 10373.

9.1.4. Definizione dei requisiti elettrici delle carte a microprocessore

Si utilizzeranno smart card “c-less only”.

Per quanto riguarda le caratteristiche in radiofrequenza si fa riferimento alle normative ISO 14443 parte 1 e 2.

Le carte dovranno essere conformi per quanto concerne il protocollo RFID alla normativa ISO 10373 – parte 6.

10. Carte a memoria (Chip on Paper)

10.1. Requisiti tecnici carta a memoria (CoP)

10.1.1. Introduzione

Il progetto BELL prevede, oltre l'utilizzo di una di smart card, anche la possibilità di utilizzare delle card a basso costo (CoP: chip on paper).

Questo documento fornisce le specifiche tecniche dei supporti leggeri (chip-on-paper) nell’ambito del progetto BELL, in particolare il supporto “leggero” scelto è Mifare UL.

Per motivi tecnici è opportuno che sia un soggetto unico a gestire i seguenti aspetti:

• Definizione e distribuzione delle carte a memoria

• Definizione e distibuzione delle SAM e metodologia di interoperabilità

• Definizione dei valori utilizzati per ogni campo della struttura adottata nelle carte a memoria

10.1.2. Funzionamento delle carte Mifare Ultra Light

Nel sistema di bigliettazione BELL verranno utilizzate delle carte a memoria a basso costo per la vendita di Titoli di Viaggio.

Saranno utilizzate carte a memoria, impropriamente chiamate “Chip on Paper” per il fatto che sono costruite utilizzando un supporto cartaceo di spessore 0,4mm.

I Chip on Paper hanno una capacita di memoria di almeno 512 bit organizzata in 16 pagine di 4 byte ciascuna. Nella seguente figura è riportato il layout della memoria della carta.

89/93

10.1.3. Codice seriale carta (serial number)

La pagina 0 contiene la prima parte del serial number e il relativo byte di controllo, la pagina 1 contiene la seconda e ultima parte del serial number, la pagina 2 contiene il byte di controllo relativo alla seconda parte del serial number. Il codice del produttore si trova nel byte SN0 che è anche il byte più significativo del serial number.

Il codice seriale della carta è formato da 7 byte. Esso identifica univocamente la carta a livello di bacino progetto BELL. L’attribuzione dei range di codici alle diverse forniture dovrà esse- re definita con il committente in sede di stipula del contratto).

Di seguito viene riportata la figura relativa alla gestione del serial number all’interno della memo- ria della carta.

10.1.4. Lock byte

La pagina 2 contiene anche due byte di lock suddivisi:

• un bit di lock per ogni pagina dalla 3 alla 15, se tale bit viene posto a 1 la relativa pagina di memoria diventa read-only (totale 12 bit)

• block-locking bit uno per la pagina 3, uno per le pagine da 4 a 9 e uno per le pagine da 10 a

15. Una volta posti ad 1 tali bit impediscono di cambiare lo stato dei lock bit delle relative pagine di memoria (freeze della configurazione read/write delle zone di memoria).

Questi due byte sono di tipo OTP, l’unica azione possibile e irreversibile è quella di porre i bit da 0 a 1.

10.1.5. OTP byte

La pagina 3 contiene 32 OTP bit. In fase di produzione tali bit sono disposti a 0 e una volta settati a 1 non possono piu essere cambiati (funzione utile come contatore per i carnet e per incrementare la sicurezza).

10.1.6. Requisiti fisici e meccanici

Lo standard che definisce il ticket è l'EN753-2. Lo standard di comunicazione utilizzato dalle carte Mifare UL e ISO 14443-A e 2641permette una trasmissione dati fino a 106 kBit/s.

Caratteristiche fisiche:

• dimensioni: 85,6x54mm (ISO standard), con angoli arrotondati

• spessore: minimo 0,180 gr/m2, massimo 0,250 gr/m2

• finitura: carta adatta per personalizzazione con stampanti a trasferimento termico

• fan-fold da 10 unita , piega ogni unita ;

• forza di separazione compresa tra 40 e gli 80 N.

10.1.7. Durata della smart card

I processi produttivi delle carte devono garantire una durata di almeno 4 anni e pertanto devono essere particolarmente curate le seguenti attivita :

• l'embedding, soprattutto in relazione al collegamento dell'antenna al microprocessore,

• la stampa in laser engraving e tutte le attivita produttive che possono causare stress meccanici ed elettrici.

A tale proposito si rammenta la conformita alle norme citate nel paragrafo 2.1.3 per quanto riguarda le caratteristiche fisiche ed in particolare ISO/IEC 14443 -1 paragrafo 4 e le relative norme collegate (ISO/IEC 10373).

11. Appendice A

(informativa)

Le seguenti precisazioni vengono fornite allo scopo di chiarire gli aspetti volontariamente non trattati dal testo normativo:

• Si noti che attraverso la struttura definita in questo documento l’applicazione di tra- sporto può essere alloggiata su qualsiasi tipo di supporto per permettere una migra- zione graduale tra le carte attualmente utilizzate e la carta Calypso rev. 3.1. Inoltre lo stesso supporto può alloggiare più applicazioni descritte nel presente documento. Può ugualmente alloggiare altre applicazioni totalmente indipendenti.

• L’applicazione conforme al paragrafo 8.5 può autorizzare la gestione gerarchica delle chiavi (in conformità con Calypso 2) anche se la struttura di riferimento si trova su un supporto (CD97 paragrafi 8.1 e 8.2) che non supportano questa gerarchia.

Il riferimento al presente documento, in conformità con le regole di AFNOR, può essere effet- tuato in due modi:

• non datato: XP P 99-405, nel qual caso, nei documenti, contratto o accordi che si rife- riscono ad esso si applica l'ultima normativa pubblicata al momento della firma o della data di riferimento indicata nel contratto.

• datato: XP P 99-405:2002, nel qual caso si applica il documento che ha la corrispon- dente data di pubblicazione.

Si ricorda che Intercode è stato pubblicato per la prima volta nell’agosto 2002 (XP P 99- 405:2002), nel dicembre 2003 (XP P 99-405:2003) e nel 2009 utilizzato per la presente edi- zione del doocumento (NF P 99-405:2008).

12. Appendice B

(informativa)

Selezione dell’applicazione di bigliettazione su un supporto

Al momento della pubblicazione della presente versione del documento, sono in circolazione numerose applicazioni Intercode che non rispettano il nuovo requisito di nomenclatura dell’AID, che dovranno coesistere per molti anni con i nuovi supporti che invece rispetteranno questo requisito.

Quella proposta qui sopra è una modalità di gestione che permette di trarre profitto dai vantag- gi apportati da questo obbligo di nomenclatura, pur gestendo il parco già distribuito. Questo comporta due elementi:

• da una parte una restrizione sui nuovi supporti distribuiti. Essa ha come scopo di evita- re l’emissione di supporti che necessitano una selezione dell'applicazione tramite AID senza d'altro canto che un'apparecchiatura possa distinguerli dai supporti già distribuiti;

• d’altra parte un trattamento che tragga profitto dalle caratteristiche particolari dei sup- porti già distribuiti per riconoscerli, e inoltre metta in opera la selezione tramite AID sol- tanto sui supporti per i quali è applicabile.

Restrizione nell’emissione di nuovi supporti

La restrizione che deve essere messa in opera consiste nel non emettere applicazioni di bi- gliettazione Intercode su un supporto che dialoga con il protocollo Innovatron e che ha una ri- sposta alla messa in tensione (Answer To Reset, o ATR) identica a quella di uno dei quattro supporti di riferimento descritti nei paragrafi da 8.1 a 8.4, in quanto questa applicazione neces- siterà una selezione tramite il nuovo AID e un trattamento differente da quello effettuato sull’applicazione di uno dei quattro supporti di riferimento.

ESEMPIO Xxxxx in opera di questa restrizione: divieto di emettere una carta che dialoga con protocollo Innovatron, che ha lo stesso ATR della CD97-2 descritta al paragrafo 8.1 e conte- nente una seconda applicazione di bigliettazione Intercode oltre a quella già presente inizial- mente. Peraltro una carta del genere, avente una seconda applicazione bigliettaria Intercode, ma con un ATR differente, o dialogante con il protocollo ISO/CEI 14443 al posto del protocollo Innovatron, è senz’altro possibile.

Trattamento suggerito di un supporto presentato a un’apparecchiatura

Nel momento in cui viene applicata la restrizione precedente, il trattamento suggerito per sele- zionare la giusta applicazione Intercode su un supporto presentato a un'apparecchiatura (che sia precedente alla versione attuale del documento o che sia conforme a questa versione) è il seguente:

• se il supporto risponde al protocollo Innovatron con una risposta alla messa in tensione (ATR) identica a quella di uno dei quattro supporti di riferimento descritti nei paragrafi da 8.1 a 8.4, allora l’apparecchiatura deve considerare che il supporto non contenga che un’unica applicazione Intercode, totalmente identica a quella del supporto di riferi- mento corrispondente. Il trattamento da applicare è pertanto lo stesso che si utilizza sul supporto di riferimento, e in particolare non si ricorre alla selezione per AID (che può essere assente o indefinito come sul supporto di riferimento) ma si privilegia una sele- zione implicita;

• in tutti gli altri casi (supporto che dialoga con un protocollo diverso dal protocollo Inno- vatron, o che dialoga con il protocollo Innovatron ma inviando un ATR diversa da quella dei quattro supporto di riferimento descritti ai paragrafi da 8.1 a 8.4), allora il supporto è considerato conforme alla presente versione del documento, e l’applicazione Intercode da utilizzare deve essere selezionata tramite il comando dedicato (SELECT APPLICA- TION).