Electronic ticketing system
Download
Report
Transcript Electronic ticketing system
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: [email protected]