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:
1. Build: acquire and implement the system
2. Operate: maintain and operate during 12 years the
whole system, distribute tickets, manage a call
center and communicate to customers
3. Transfer: at the end of the BOT agreement, the
system belongs to Rigas Satiksme
Business Model Summary
Monthly fees
equity
dividends
51,0%
49,0%
equity
BANK
Loan
dividends
Fixed Assets=
Back-Office
Front-Office
Contactless
Cards & Tickets
Supplier
Equity
LT Debt
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
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