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

2. Riga Transport System
Operator: Rigas Satiksme, 100% municipal company, 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
trips per day

3. 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

4. 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

5. 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

6. Ticketing System Layout

7. 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

8. 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

9. 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

10. 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)

11. 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

12. 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

13. 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.

14. 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

15. 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

16. Conclusion Any question? Thank you... For information please contact:
Pavels Tulovskis, Technical director