Riga

1
Rigas e-Ticketing System
Interoperability possibilities Pavels
Tulovskis, Rigas Karte
2
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

3
Rigas Karte

• Joint Venture between Rigas Satiksme and
  Affiliated Computer Services
• Objective Build, Operate and Transfer the bus,
  tram and trolleys 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
dividends
equity
Monthly fees
equity
BANK
Loan
dividends
Fixed Assets Back-Office Front-Office
Equity LT Debt
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, parkride 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 opportunitiesFare 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

• 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 exampleConditions

• 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 exampleSolution

• 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 Email pavels_at_rigaskarte.lv