Riga’s e-Ticketing System “Interoperability possibilities” Pavels Tulovskis, Rigas Karte

Riga Transport System Operator: Rigas Satiksme, 100% municipal company, 150 M€ revenue per year, operating public transport and city parkings Fleet: 460 buses – 56 routes 322 trolley buses – 22 routes 252 Tramways – 11 lines Ridership: Over 300 millions passengers per year 500 000 trips per day

Rigas Karte Joint Venture between Rigas Satiksme and Affiliated Computer Services Objective: Build, Operate and Transfer the bus, tram and trolley’s ticketing system of Riga city: Build: acquire and implement the system Operate: maintain and operate during 12 years the whole system, distribute tickets, manage a call center and communicate to customers Transfer: at the end of the BOT agreement, the system belongs to Rigas Satiksme

Business Model Summary Monthly fees equity dividends equity BANK Loan Fixed Assets= Back-Office Front-Office Equity LT Debt dividends Contactless Cards & Tickets Supplier Technical sub-contractors - installation - maintenance Ticketing Solution

ACS Atlas ticketing system Basic features: Open technology: open to various types of cards, tickets, NFC, contactless bank cards… Multimodal: open to various transport means: buses, trolleybuses, trams, regional trains, taxis, park&ride systems etc... Multi-operators: collecting and processing data from several transport operators with ensuring security and confidentiality between the participating operators Interoperable Open to fare products issued by other transport networks

Ticketing System Layout

Level 0: contactless fare media Atlas system accepts any type of standardized cards Two types of fare media to divide functionality Calypso CD21 smart card Mifare UL tickets

Mifare UL contactless ticket Usage: 5 days tickets 5, 10, 20 trip tickets Structure: 512 bit EEPROM, organized in 16 pages of 4 bytes 32 bit one-time programmable (OTP) area 384 bit read / write area for user data Security: SAM based digital signature including 7 byte unique serial number

Calypso CD21 smartcard Usage: Monthly products Personalized card, Agent card Structure: Card - CD21 (CD97-BX structure 2) 8K EEProm Cryptography – DESX 120bit Security – SAM S1 Protocol – ISO/Innovatron Applications: Ticketing DF (Intercode compatible data mapping) 8 contracts 3 log events 4 securized counters E-Purse Multipurpose application

Fare media security principles SAM – Security Application Module Type Spitrtech SAM S1 Manages up to 62 crypto keys A key may be used for: Calypso card transaction management (validation, reloading) Data certification management (contactless tickets) Others SAMs management (selling SAM reloading)

SAM Key management Different SAM types in the specific network Pre-Personalization: load keys during card manufacturing Personalization: load initial card data Master: manufacture SAMs Reloading: reload a new contract to a card Validation: verify and register the card in vehicle

Integration opportunities Fare media level Using completely different cards Each operator issues its own cards and agreements Other operators could share Validation and control Sales of contract After sales services (customer care, etc.) Several independent transport applications Similar to previous point Agreement of card emission Customer care (full card reconstruction in case of breakdown Single transport application on the same card Common set of keys used Could share “local” contracts and “interoperable” contracts

Interoperability example City A and City B Each city has its own transportation network and fare media Objective: to allow City A validators to process City B cards and for City B validators to process City A cards Condition: Each transportation network (City B and City A) could issue only its own products but it can validate and control both products.

Interoperability example Conditions Fare media distribution: each city should distribute its own fare media Card profile maintain / modification: both has to modify their own profiles Contracts loading: each network support its own contracts Contracts validation: each network validates its own contracts and interoperable contracts Data exchange: blacklist, validation activities

Interoperability example Solution Card data split into two categories Fixed section - contains profile/status data Variable section - updates on every sale or validation Shared partition will be constituted by data which will be updated after a validation or a transfer. These data are: Validity start and end of validity of the card Blocked/non blocked bit Validity start and end of validity of the trip

Conclusion Any question? Thank you... For information please contact: Pavels Tulovskis, Technical director Email: pavels@rigaskarte.lv