Report to / Rapport au:

 

Transportation Committee / Comité des transports

 

and Council / et au Conseil

 

23 August 2006 / le 23 août 2006

 

Submitted by / Soumis par: R. G. Hewitt

Acting Deputy City Manager / Directeur municipal adjoint par intérim,

Public Works and Services / Services et Travaux publics

 

Contact/Personne-ressource: A. Carle, Director / Directeur,

Transit Services / Service du transport en commun

842-3636 ext. 2271, alain.carle@ottawa.ca

 

 

City Wide

Ref N°:   ACS2006-PWS-TRN-0004

 

 

SUBJECT:     SMARTCARD FARE SYSTEM

 

OBJET:          SYSTÈME D’ENCAISSEMENT DES TARIFS PAR CARTE À PUCE

 

 

REPORT RECOMMENDATION(S)

 

That the Transportation Committee recommend Council approve:

 

1.                  The Smartcard System Concept and Functional Requirements as shown in Attachment 1; and,

2.                  The commencement of the procurement process in advance of actual approved budgets, as an exception to the requirements of the Purchasing By-law, with the stipulation that the Request for Proposal (RFP) document contain a clause stating that any award as a result of this procurement process will be subject to the approval of budgetary funding by City Council in the 2007 budget and beyond.

 

 

RECOMMANDATION(S) DU RAPPORT

 

Que le Comité des transports recommande au Conseil d’approuver :

 

1.                  Le concept et les exigences fonctionnelles du système d’encaissement des tarifs par carte à puce décrit à l’annexe 1;

2.         Le lancement du processus d’acquisition avant que les budgets n’aient été approuvés, en tant que dérogation aux exigences du Règlement sur les achats, à la condition que la demande de propositions renferme une clause indiquant que le contrat qui sera attribué à la suite de ce processus d’acquisition sera conditionnel à l’approbation des crédits budgétaires par le Conseil municipal en 2007 et au-delà.

 

 

BACKGROUND

 

Transit Services has followed the progress of electronic fare payment systems in the transit industry, and particularly contactless Smartcard systems, for over 10 years.  In 1997, IBI Group was retained to carry out a fare system study for OC Transpo with the emphasis on Smartcards.  In April 1997, the Transit Commission approved the introduction of an electronic transfer-issuing machine as a first step towards an electronic fare system but recognized that, at that time, the technology had not developed to the point at which a positive business case existed for a full smartcard fare system.  Electronic transfer issuing machines were successfully installed on the transit fleet following that decision.

 

In 2003, a study was carried out by KPMG to determine the role of Smartcards within the City and specifically whether a Smartcard fare payment system was now suitable for implementation for OC Transpo.  The study included an examination of the business case, given the current experience of Smartcard technology in the transit industry.  This work was updated in 2005 to reflect the requirements for fare collection of the Light Rail Transit (LRT) system.

 

The major recommendations of the KPMG([1]) report were:

 

·          That it would be cost-effective to implement a Smartcard Fare Payment system for OC Transpo; and,

·          The City should adopt the development of a multi-application Smartcard as a long-term goal, with transit as the first step.

 

The key advantages of a Smartcard fare payment system, as outlined in the KPMG report, are that it would:

 

·          Enable the launch of a ‘Personal Ecopass’ to build upon the successful Ecopass program now in operation.  The Smartcard Fare Payment system would provide the necessary controls, mainly the blacklisting of invalid cards.  The Personal Ecopass would offer convenience to all customers in that they would no longer have to obtain a new pass each month, encourage increased ridership and provide ‘equity’ between all customers by making the pass available to everyone;

·          Provide a fare system compatible with Société de Transport de l'Outaouais (STO), that has already implemented a successful Smartcard Fare Payment system.  This would provide additional customer convenience and operational efficiencies;

·          Simplify the fare verification process and reduce fare fraud;

·          Provide a way to allow ‘tickets’ to be accepted on LRT by having customers use the stored value feature of the card;

·          Support the integration of bus and LRT fare payment and proof of payment systems;

·          Provide a means to introduce new fare and pricing initiatives that would contribute to attracting new customers and building ridership; and,

·          Improve the image of transit.

 

The KPMG report emphasized that Smartcard system technology is now mature with many transit operations across North America with systems in operation, in the process of implementing, or actively planning to implement systems.  As well, Smartcard systems are being implemented at an increasing rate in cities around the world.

 

The KPMG analysis produced a positive business case.  Much of the improvement in the business case since 1997 was due to the decrease in prices of the smartcard readers and the smartcards themselves.  Another key driver of the positive business case was that the Smartcard system could leverage the GPS SmartBus system now in the final stage of implementation on all buses.  The Smartcard system would make use of the SmartBus Mobile Data Terminals thus eliminating the need to purchase this as part of the smartcard contract.  The payback period was under seven years, which is reasonable for a system that has a lifespan of at least ten years.

 

In late 2005, staff moved forward with the next step in the process to:

 

 

This work was carried out by an experienced team from IBI consultants, following an open procurement process, and forms the basis for the recommendations in this report.

 

 

DISCUSSION

 

Smartcard Fare Payment System Description

 

Attachment 1 provides the details of the recommended Smartcard system concept.

 

It is recommended that a proximity-based Smartcard Fare Collection system be introduced on all OC Transpo service.  It is important that it be in place in time for the implementation of LRT service in early 2010.  The timetable for the Smartcard Fare Payment system will see the introduction of Smartcards configurable as any form of prepaid pass (monthly, semester, annual, Ecopass, etc.) in 2008 followed by the implementation of the ‘purse’ or stored value feature in late 2009.

 

The system will make use of contactless smartcards and readers.  Contactless cards are widely used in the transit industry because they allow rapid boarding and the maintenance requirements of on-bus units, with no moving parts, are much lower than for magnetic strip cards.  Customers will be able to configure their cards as any one of a number of possible period passes (Ecopass, annual, monthly, semester for students, etc.) that will allow unlimited use during the period paid for.  In addition, customers will be able to ‘load’ the card with money and have the fare for a trip deducted from the card.

 

Customers who do not have a Smartcard will be able to pay their fare with cash on all buses or purchase an electronic  ticket from vending machines at on all light rail platforms.  The light rail vehicles will not have any fare equipment on board, including fare boxes or smartcard readers.

 

When the system is introduced, there will be a card reader on each bus and card validators on light rail station platforms.  Smartcards will be issued  issued and recharged at OC Transpo Sales and Information offices, at approximately 100 vendors and at 70 machines located on station platforms along the LRT line.  It will also be possible to replenish cards through the internet, by telephone or by pre-arranged direct debit.  The card readers will be able to read STO smartcards, and the STO readers will be able to read OC Transpo cards.

 

A back-office system will manage the information to and from the on-bus readers, the revaluing machines and card validators.  It will keep track of fares collected and ensure that only valid cards can be used.

 

Electronic ticket transactions on OC Transpo buses with STO cards will be tracked, as will electronic ticket transactions on STO buses with OC Transpo cards.  The difference will be balanced through a cash transfer between the agencies.

 

The application of a Proof of Payment (POP) system will be a key feature of the new Smartcard Fare Payment system.  OC Transpo currently operates a POP system on 225 articulated buses and on the existing O-Train.  Customers who have a valid pass can board articulated buses by the rear doors and do not have to pass by the bus operator and customers can board the O-Train through any door.

 

The operation of POP will be expanded throughout the new LRT system.  Wherever possible, new LRT stations will include POP platform areas (fare-paid zones).  All station platforms will be equipped with smartcard readers and smartcard value replenishment machines.  The enforcement of POP will be done with portable smartcard readers as part of the new Smartcard system.

 

The Smartcard system will allow seamless travel between bus and light rail services as well as seamless travel for customers transferring between OC Transpo and STO transit systems.  STO already uses a Smartcard fare payment system.  The compatibility of the OC Transpo and STO systems is a central requirement, with STO in full support of this initiative.

 

The system will be implemented so that fare-by-distance can be added in the future, although the initial system will not include this feature.

 

Other City departments have shown interest in the Smartcard application and possible benefits.  Wherever possible, the Smartcard system will be designed using open architecture and will consider the needs of other City departments.  As well, future opportunities for partnering with educational institutions, whose students form a large and important portion of our customer base, will be investigated.  In the future, the system will provide a wide range of opportunities for partnerships and shared promotions.  Examples of this would be the use of the cards to pay for or gain a discount on tickets for special events or for products in stores.

 

Implementation Time Lines

 

The plan to implement an electronic Smartcard Fare Payment system in time for the opening of the LRT system requires the release of the Request for Proposal for the system this fall.  Since funding for the system beyond 2006, although included in LRFP2, is not yet approved, an exception to the requirements of the Purchasing By-law would be required to proceed.  It is recommended that this be approved, with the stipulation that the RFP document contain a clause stating that any award as a result of this procurement process will be subject to the approval of budgetary funding by City Council in the 2007 budget and beyond.

 

Staff would present a report to Transportation Committee early in 2007, after selecting the preferred supplier of the system, seeking approval for funding to proceed with the project.  Once approved, the system would be implemented in the following two main phases:

 

 

 

Estimated Cost for the System

 

IBI Group provided the cost estimates based on the requirements for the system and their knowledge of recent price developments in the smartcard industry serving transit applications.  The total cost to implement the system is estimated to be about $15.0 million.  This covers all costs including smartcards, on-bus readers, LRT station platform card validators and replenishment machines, central back-office and supporting software, an allowance for marketing the new system, implementation, contingency and taxes.

 

Business Case

 

The business Case for the Smartcard Fare System is summarized in Attachment 22.  .

 

The cost for the 70 LRT station platform card replenishment machines, required to support the proof of payment system for LRT, was included in the total estimated cost. However, for the business case, this cost was not included.  If a smartcard system were not being considered at this time, the LRT fare payment system would still require sophisticated mechanical machines similar to those used in Calgary and Edmonton for their LRT systems.  These machines would accept bus tickets to be inserted and validated for proof of payment.  As well, customers would be able to buy strips of tickets or to pay the single cash fare and receive a validated ticket. Based on the experience of Calgary and Edmonton, the cost to buy and install the 70 machines would be about $3.5 million. Therefore, the cost applied to the business case for LRT platform machines only represents the additional cost above the $3.5 million to accommodate smartcards.  This cost is estimated to be about $350,000.

 

The approach to the business case was based on the net present value calculation.  The net present value combines the initial estimated capital costs with the projected annual costs over the anticipated ten-year economic life of the system.  These projected annual costs include the system operating costs, savings in existing operating costs, and revenue impacts.  The business case assumed an expected system life span of ten years, however, the actual life of the system is expected to be at least that long.

 

The business case prepared by IBI Group was very thorough and highly detailed.  The net present value over the ten-year period is $6.3 million with an expected payback period between five and six years.

 

Competitive Bidding Process

 

The opportunity to bid on the Smartcard Fare Payment system should attract interest from all major smartcard system suppliers and system integrators who specialize in, and have experience with smartcard systems.  The competitive bid process to be followed in the selection of the successful proponent will follow the procedure stipulated in the Purchasing By-Law, as it relates to the issuance of a Request for Proposal. involve two stages.   IBI Group has prepared functional specifications and detailed terms of reference that will form the core of the RFP.

 

The evaluation of the proponent submissions will be based on a number of criteria that will ensure the best supplier is selected. Factors to be used in the evaluation include:

 

·          Experience and knowledge of staff - proponent must demonstrate staff are experienced in all aspects of the project;

·          Previous implementations and references - it is critical that the selected proponent have a solid track record in successful smartcard fare system implementations and that customers confirm their satisfaction with both the results and the supplier;

·          Compliance with mandatory requirements - must comply with all mandatory requirements;

·          Flexibility - demonstrated ability to be flexible and adapt to unique requirements of the system;

·          Workplan and timetable - the schedule for the system is tight. The supplier must demonstrate the ability to successfully deliver the system to meet the timelines; and,

 

City staff intend to allocate point weightings to the suggested criteria in advance of the RFP being issued, and will also convene an evaluation committee of knowledgeable senior staff, and external consultants, in order to review the proposal submissions.First, proponents will respond to a request for qualifications.  The evaluation at this stage will determine whether the proponents are compliant with the technical requirements of the system.  For the second stage, only those proponents that are compliant will be invited to submit a price for the system.  The final selection at this point will solely be based on price, as all submissions will be technically compliant.

 

 

ENVIRONMENTAL IMPLICATIONSOptional - delete if not applicable

 

 

RURAL IMPLICATIONSOptional - delete if not applicable

 

 

 

 

CONSULTATION/PUBLIC NOTIFICATION

 

The Pedestrian and Transit Advisory Committee has been consulted about this project and is supportive of the recommended approach. STO staff have been very much involved in the project to date and discussions will continue to ensure that the OC Transpo and STO systems can be integrated seamlessly.

 

 

 

TRANSPORTATION MASTER PLAN

 

The introduction of a smartcard fare system will build transit ridership by enhancing opportunities to promote and market transit and increasing customer convenience. (for TUPW – use only if applicable)

 

 

 

FINANCIAL IMPLICATIONS

 

The 2006 approved capital budget contains $1.0 million in funding for this project of which $0.5 million will remain after the payment to IBI Group.  The capital cost of the smartcard system is expected to be in the order of $15.00.7 million over the 2007 to 2009 implementation10 implementation period.  Therefore, a request for the balance of $9.714.5 million in funding required for this project will be included in the 2007 Draft Capital Budget submission.  .

 

 

 

SUPPORTING DOCUMENTATION 

 

Attachment 1 – Smart Card System Concept and Functional Requirements

Attachment 2 – Smart Card Business Case Summary

 

 

 

DISPOSITION

 

Following approval of these recommendations, staff will finalize the RFP for the fare system and release it on MERX.  Staff will present a report to Transportation Committee early in 2007, after selecting the preferred supplier of the system, seeking approval for funding to proceed with the project. 


 

ATTACHMENT 1

City of Ottawa

Smart Card System Concept and Functional Requirements

Technical Memorandum - Revision 3.0

June 2006


DOCUMENT CONTROL

Client:

City of Ottawa

Project Name:

Development of Smart Card Terms of Reference

Report Title:

Smart Card System Concept and Functional Requirements

IBI Reference:

TO - 11182

Version:

3.0

Digital Master:

TTR_functional requirements_OSCToR_2006-06-19.doc

Originator:

Muhammad Mustafa

Richard Neslon

Yuval Grinspun

Reviewer:

Muhammad Mustafa

Paul Lavallee

Authorization:

Scott Stewart

Circulation List:

OC Transpo

IBI Group Internal

History:

Draft outline, May 08, 2006

Final outline, May 11, 2006

Draft report, May 23, 2006

Revised Draft, May 29, 2006

Revised Draft, June 05, 2006

Revised Draft 2.0, June 19, 2006

Final, July 11, 2006

 

 

 

1.       Introduction. 13

1.1     Background.. 13

1.2     Purpose of the Report 13

1.3     Structure of the Report 14

2.       Smart Card Operational concept. 15

2.1     Smart Card Technology Background.. 15

2.2     Smart Card System Components. 16

2.3     Smart Card System Architecture. 18

2.4     Smart Card Applications and Implementation Strategy. 22

2.4.1  Transit Application. 22

2.4.2  Compatibility with Société de transport de l'Outaouais (STO) 22

2.4.3  Future Applications. 22

2.4.4  Implementation Strategy. 24

3.       Functional requirements. 25

3.1     Overview.. 25

3.2     Approach and Assumptions. 25

3.3     Smart Card Project Objectives. 25

3.4     Smart Cards. 26

3.4.1  General 26

3.4.2  Standards and Platforms. 26

3.4.3  Technical Requirements. 27

3.4.4  Fare Products and Discounting Structures. 27

3.4.5  Other Supported Applications. 28

3.4.6  Card Graphics and Serialization. 28

3.4.7  Issuance, Personalization, Registration, Updating, and Replenishment 29

3.4.8  Card Replenishment 29

3.4.9  Security Provisions. 30

3.5     Acceptance Devices. 30

3.5.1  Validity of Accepted Media. 30

3.5.2  General 30

3.5.3  On-bus Readers. 31

3.5.4  Station Validators. 32

3.5.5  Hand-held Inspection Devices. 33

3.6     Garage and Station Computer Systems. 33

3.6.1  Garage Computer System.. 33

3.6.2  Station System.. 34

3.7     Central System... 35

3.8     Customer Service Systems. 36

3.8.1  General 36

3.8.2  Issuing a Personalized Smart Card. 38

3.8.3  Issuing a Non-Personalized Smart Card. 39

3.8.4  Registering a Smart Card. 39

3.8.5  Reissuing a Smart Card. 39

3.8.6  Replenishing a Smart Card. 40

3.8.7  Suspending or Blocking a Smart Card. 41

3.8.8  Surrendering a Smart Card. 42

3.8.9  Refunding Value Remaining on a Smart Card. 42

3.8.10 Updating a Smart Card. 43

3.8.11 Querying a Smart Card or Smart Card Account 43

3.8.12 Ticket Vending Machines. 43

3.8.13 Operator and Administrator Cards. 43

3.9     Fees. 44

 

 


1.       INTRODUCTION

 

1.1       Background

 

The City of Ottawa is interested in procuring a Smart Card based fare collection system for its transit services. The Smart Card fare collection system will apply to OC Transpo’s bus operation and O-Train service and will be available in time for the expansion of light rail services in the fall of 2009.

 

The Smart Card system will make use of contactless technology. The system will provide several transit products including period passes (Ecopass, annual, monthly, semester for students, etc) that will allow unlimited use during the period paid for as well as electronic purse (e-purse) for single rides.

 

Customers will be able to get their cards and replenish them with money at specific locations and have the card accepted (for period passes users) or fare for a trip deducted from the card (for e-purse users). Customers who do not have a Smart Card will still be able to pay their fare with cash on all buses or purchase a ticket from vending machines at all light rail platforms and at some major Transitway stations.

 

IBI Group was retained by the city of Ottawa to develop Terms of Reference for the system procurement and related tasks. The scope of work for IBI Group in this project includes the following:

 

·         Develop Terms of Reference for a Smart Card based fare collection system;

·         Update and detail the Smart Card business case;

·         Assessment of impacts on current systems, business process and organisational structure; and

·         Assist in Smart Card vendor selection.

1.2             Purpose of the Report

 

This report summarizes the development of a Smart Card system concept for transit services for the City of Ottawa. The system concept is developed based on operational and business requirements identified by the transit service business groups through interviews and workshops with the consultant. This concept serves as the foundation through which requirements will be collected and presented for the final Terms of Reference. Included as part of the system concept is a high-level system architecture for the Smart Card Fare Collection System. The architecture provides a graphical representation of the various components within the system and how they inter-relate.

 

The report presents high-level functional requirements describing what functions the Smart Card system will provide to address operational and business requirements for OC Transpo’s environment.  The functional requirements will be broken down logically by service areas which map main system components defined in the smart card system concept.

 

The system concept and functional requirements provided in this document will represent the key functions to be provided by the system, and will, in turn serve as the initial set to be expanded in the preparation of the Terms of Reference. In addition, this document describes how the City of Ottawa Smart Card system will operate, and what functions it will provide.  Thus, in addition to guiding the development of the Terms of Reference, the system concept and functional requirements will also form main input to other project tasks of business case update and impact assessment.

 

1.3             Structure of the Report

 

This report is structured as follows:

 

·         Section 1 provides an introduction and background to the project and the document;

·         Section 2 presents the Smart Card system concept, including high level system architecture;

·         Section 3 summarises key functional requirements of the smart card system.


2.         SMART CARD OPERATIONAL CONCEPT

 

2.1       Smart Card Technology Background

 

A “Smart Card” is a credit card sized card that can be defined as a portable programmable device containing an integrated circuit ‘Chip’ which stores and processes data.

 

The smart card is powered up and becomes operational only when connected to a “read/write” device. The interaction between the card and the read/write device can be either direct “contact” by inserting the card into a reader slot or through a radio frequency inductive field “contactless” or “proximity” by waving/touching a card to a reader. See Exhibit 0‑1 and Exhibit 0‑2 for different card types and readers. The distance between the card and the reader varies, however for transit fare collection application this distance is about 0 to 4 cm.  The contactless card is preferred for transit applications because it permits faster processing (in milliseconds) compared to the contact card which requires more processing time (2 to 3 seconds).  The contact card is preferred by the banking industry. Some cards (called dual interface or Combi cards) have both contact and contactless interface capabilities which can be used for multi-applications such as transit payment, banking, etc.

 

Embedded in the cards are microprocessor computer circuits (or chips) used to store and process data. The performance in terms of what and how much the card can do depends on the type of chip that is used.  There are two main types of chip, the memory chip and microprocessor chip.

Memory chip cards are similar to magnetic stripe cards but offer a greater memory capacity, are more resistant to environmental factors and have higher security.   Information can be stored in the memory chip of the card allowing the card to perform several different functions. The memory size requirement depends on the number of programs and data to be stored on the card.

Microprocessor chip cards are processor cards that feature an operating system.  The operating system allows for greater comprehensive security verification than the memory chip and has the ability to perform a variety of other functions. It can house whole subprograms and execute structured data operations.

a) Contact

b) Contactless

c) Dual Interface

 

Exhibit 01 Smart Card types

 

 

 

a) Contact

b) Contactless

Exhibit 02 Examples of smart card readers

Transit fare products can reside on a transit Smart Card.  The card can hold stored rides, act as a period pass or store value “e-purse”.  Use of the card can be limited by time period (day, week, month, semester), by the number of rides or by a combination of time and rides (ride frequency).

 

In general, key advantages of Smart Cards for transit fare collection application are the following:

 

·         Increase customer convenience by simplifying payment process

 

·         Supports “seamless” travel among different transit properties

 

·         Secure and auditable revenue and data reconciliation

 

·         Flexibility to introduce new fare products, policies & incentives to increase revenues and/or ridership

 

·         Administrative & operational efficiencies

 

·         Reduce fare evasion and fraud

 

They are particularly advantageous from a transit perspective where multiple transit agencies are involved.  One card can be used to create “seamless” travel with usage recorded for revenue sharing purposes. This will be of particular interest to OC Transpo and STO customers.

 

With the interest and involvement by different industries, there is now a convergence of multiple applications for Smart Cards such as transit, banking, other municipal services (parking, recreational facilities, libraries) and the development of loyalty and discount schemes.

 

The trend toward “Smart Bus” systems (Automatic Vehicle Location, on-board customer information, diagnostics and driver information) point the way towards “smart” systems for fare collection as well.  All systems can be linked thereby creating a wealth of information for service planning, budgeting and personnel management.

 

 

2.2       Smart Card System Components

 

A Smart Card system is comprised of various components, as summarized below:

 

·         Smart CardSmart Card technology is highly flexible, with varying levels of functionality and respective price.  In general, there are three types of cards that are applicable to transit:

-         Disposable – these cards offer limited processing/memory capability and cannot be replenished once the value on the card is depleted.  These cards are the cheapest and often only provided for the casual rider, or for promotional purposes;

-         Baseline Contactless– these cards provide processing/memory capability that meets the basic functions desired for a transit smart card system.  The validity or value on the card can be renewed or replenished. These cards are typically used to replace transit’s various monthly pass and ticket fare products;

-         Dual-interface cards – these cards have both a contact-based and contactless interface, providing for added functionality compared to the baseline card.  An example would be having a Smart Card with transit application using contactless interface and a parking or banking application using the contact interface.  These cards are more expensive and would only be of interest if multiple applications are envisioned.

·         Smart Card Reader – Smart Card readers interface with the Smart Card, powering it and performing the necessary transactions. In the case of OC Transpo, the readers would be installed at the front doors on all OC-Transpo buses.

·         Smart Card Validator – Smart Card validators are similar to on-bus readers in functionalities but will be installed at all LRT stations. 

·         Portable (handheld) device – Handheld devices will be employed by fare inspection staff on the Proof-of-Payment services including articulated buses and LRT services.

·         Automatic Vending Machine – Vending Machines can be deployed to allow customers to replenish their cards or to print tickets/transfers on Proof-of-Payment services. They can be made to accept cash, credit card, debit card, etc. with further options given to identify the length of trip (in cases of zone-based fare charges).  Once the transaction is completed, an embedded thermal printer provides the passenger with a time-stamped receipt that identifies the necessary information (i.e. destination, fare product, etc.).

·         Customer Service Equipment – Sales centre and customer service staff will be provided with equipment to both access and manage existing smart card accounts as well as to create new ones. This will include the following sub-components:

-         Smart Card reader to accept and access customer accounts in order to replenish their accounts;

-         Digital Camera and Card printers to issue new Smart Cards;

-         Computer Terminals to input relevant account modifications/information.

Some of the above functions will be provided at third party vendor network.

·         Garage Computer System – The vehicle garages will be equipped with a computer terminal and the necessary peripherals to extract a usage log from the Smart Card readers. This process will be performed every time during the standard “count-down” procedure when buses are refuelled and serviced. Thus, the probe to access the reader would be located in the garage wash bays. Smart Card reader probes may employ standard wireless interfaces (i.e. WiFi, Bluetooth, etc.)

·         Station Computer System – the LRT stations will be equipped with station computer systems. These systems will serve as interim nodes between the card acceptance devices (station validators and AVM) and the smart card central system. The station computer system would also provide customer service functions if these are provided at stations. 

·         Central System – The central system consists of the necessary servers and communication devices to ensure secure and reliable system functionality. Server and database redundancy is considered, as are regular backup procedures, to prevent loss of vital information in the event of a system malfunction. Appropriate encryption of communications and logon procedures are put in place to ensure that only authenticated users can access system information, and in particular, customer’s financial details. A workstation is typically provided as part of the suite of central system equipment for administrators to maintain the system.

 

2.3       Smart Card System Architecture

 

Smart Card systems comprise various sub-systems as described in section 0.

 

Exhibit 0‑3 presents high level system architecture for OC-Transpo smart card system. Certain sub-systems share key functions, and can be grouped as tiers that exchange data in a secured way.

 

The primary benefit of the tiered structure envisioned for the City of Ottawa Smart Card system is its security and reliability. Data stored in the Central System is protected by several layers/tiers of applications residing on other sub-systems. Thus, the risk of data corruption or loss is minimized, and in turn, usage data and associated revenue transactions are secured.

 

Data exchange between tiers does not necessarily happen instantaneously, as it is dependant on the communications interface and business rules. Realistically, it could take anywhere from milliseconds (for example, card to reader) to one day or more (for example, reader to garage computer system) to filter and transfer data between tiers. Worth to note, that once the connection is established between tiers, real transfer times would take a few minutes or even seconds. 

 

Each tier and communications interface is briefly described below.

 

Tier 1: Smart Card

 

Considered the governing component, the Smart Card held by each transit customer generally contains the most current data as it is present when most transactions take place. The exception to this follows web/phone-based account updates, whereby the customer would request a ‘reload’ and the card would be updated the next time the user accesses the transit service.

 

The card memory contains both the transit fare application and storage of relevant information. Compared to credit card transactions, the smart card can handle secure off-line transactions without any need for central system verification which keeps the overall transaction time to milliseconds. 

 

Tier 2: Card Acceptance Devices

 

This tier represents the front-line equipment for transit which customers will interact with. This includes on-board readers, station validators, handheld devices for POP enforcement, and vending machines for automatic replenishment.

 

Tier 1-2 Communications Interface

 

Tier 1 and 2 communicate via wireless RFID (Radio Frequency Identification) induction technology. The communication and security protocols for this interface are specified in the ISO 14443 standards.

 

Tier 3 Garage and Station Computer System

 

The Garage Computer System and Station Computer System are intermediary agents for data transfer between the Tier 2 and Tier 4 components. No data processing or modifications occur in these systems.

 

Tier 2-3 Communications Interface

 

Sub-systems from Tier 2 communicate through various means:

 

·         On-board readers will communicate daily with the Garage Computer System through what is likely to be a wireless LAN interface during the vehicle’s countdown procedure. As well, additional communication may be configured through an interface to the on-board Smart Bus system, which in turn connects directly to the Central System via a leased 1xRTT data service;

·         Handheld devices used by fare enforcement staff will communicate directly with the smart card to verify payment or pass validity. The data stored in the device (including smart card hot lists) is updated by the Central System, or a Station Computer System, via an RS232 or USB interface, at a policy-driven interval;

·         Vending machines and station validators will continuously communicate with the Station Computer System either through a WiFi or LAN;

·         Customer service terminals at OC Transpo issuance offices will communicate with the central system via the city LAN network;

·         Point-of-Sale machines would communicate via dial-up several times daily, as decided by OC Transpo.

Tier 4 Central System

 

The Central System represents a set of servers that are the core of the system. This will include:

 

·         Application servers;

·         Communication server;

·         Device/status server

·         Web server;

·         Print server;

·         Database and backup system.

Tier 3-4 Communications Interface

 

The Garage Computer System will connect with the Central System through one of two means, depending on location. For the garage where the Central System is housed, it will be continuously connected through the LAN. For the remote garages, regular exchanges of information will be provided via the city LAN network.

 

The Station Computer System will communicate with the Central System via the city LAN network.

 

Tier 5 Customer Service

 

Customer Service is provided through various channels, including the internet, phone and sales centres (customer service terminals). With the exception of the customer service terminals which interface directly with the Smart Card, updates/modifications to accounts made over the internet or phone will filter backwards through the Central System and Garage Systems and only be updated on the Smart Card the next time it is used once the account updates are present on the bus or at the station computers.

 

Tier 4-5 Communications Interface

 

The Central System hosts the Web, Call Centre, and databases, thus communication between the central system and Customer Service Terminals will be provided via the city LAN network.


Exhibit 03 High Level System Architecture

 

 

 



2.4       Smart Card Applications and Implementation Strategy

 

2.4.1     TRANSIT APPLICATION

 

Transit fare payment is the primary and most significant application of the Smart Card system. The system will make use of contactless Smart Cards and readers to replace the ticket and transit pass system in use today. The Smart Cards will be accepted on OC Transpo buses and on the LRT network. Cash fares will still be accepted upon introduction of the new Smart Card; customers who do not have a Smart Card will be able to pay their fare with cash on all buses or purchase a ticket from vending machines at all light rail platforms.

 

OC Transpo will maintain the current Proof-of-Payment (POP) system currently in place on the O-Train and on all 225 articulated buses. The operation of POP will also be expanded throughout the LRT system. Wherever possible, LRT stations will include POP platform areas (fare-paid zones) and all station platforms will be equipped with Smart Card readers and Smart Card value replenishment machines. The teams of fare inspectors who now enforce POP will be equipped with portable Smart Card readers as part of the new Smart Card system.

 

The new Smart Card system will support all of OC Transpo’s current fare products including monthly, semester, and annual passes for different customers, as well as the Ecopass system. For less frequent travellers, the cards will include a rechargeable purse feature that customers can use for single trips. In addition, the new system will be flexible, allowing for the simple accommodation of future expansions and modifications to the current fare structure.

 

The Smart Card system will call for a shift from the present vendor-based distribution of tickets to fewer, by introducing on-line services through internet and call centre. Also, the project team will assess the possibility of automated replenishment stations that would allow customers to manage their account, including pass payment or e-purse replenishment. The stations could be located at select merchants from the present list of vendors, or could be located at City facilities, including libraries, which have the required communications infrastructure already in place.

 

2.4.2     COMPATIBILITY WITH SOCIETE DE TRANSPORT DE L'OUTAOUAIS (STO)

 

Seamless travel and fare integration for passengers between OC Transpo and STO transit services have been in effect for over 30 years and both organizations view this as an important requirement going forward in the new smart card system.

 

The new Smart Card system will maintain the current measures of seamless travel for customers travelling on both the STO and OC Transpo systems. The new Smart Card system will operate in a manner that will allow for interaction between the two systems; OC Transpo card readers must be able to read existing STO Smart Cards, and existing (or modified) STO card readers must be able to read the new OC Transpo Smart Cards. That is, both cards shall be accepted at the front ends of each system.

 

The integration of the two payment systems will introduce a high level of data and revenue exchanges between OC Transpo and STO. The existing business rules that each agency (OC Transpo and STO) keeps the money it collects for passes and accepts others passes will remain. Currently, pass revenue is pre-assigned to the agency based on province of residence. OC Transpo passes are only sold to Ontario residents and STO passes are only sold to Quebec residents. However, limited data exchange on smart cards, blacklists and transactions (for e-purse) will be implemented between the two agency’s central systems that would provide data and reports for financial departments at both agencies for financial settlement.

 

2.4.3     FUTURE APPLICATIONS

 

Although the current focus remains on developing the transit applications, it is recognized that provisions should be made for future applications of transit Smart Cards in avenues such as schools, universities, and parking. The feasibility and opportunities of such future integration with other services is discussed below.

 

2.4.3.1  Schools

 

Smart Cards have the potential to be integrated with standard high school photo ID cards, allowing the school boards and OC Transpo the opportunity to share card issuance costs, while at the same time increasing convenience to students. Presently, Transit Services works closely with school boards and provides special transit service to high school students through the 600 series routes. OC Transpo student ridership is significant at approximately 9,000 students using the 600 series routes alone. This is apart from students who rely on the regular bus service to get to school. Consequently, there is an opportunity for the school boards and OC Transpo to create a common student ID and transit Smart Card.

 

During the external stakeholder sessions, school representatives identified benefits to having a joint transit-student ID card, with an option involving the school boards compensating Transit Services for card production costs. In addition, it was found that schools might begin to require Smart Cards or similar technology for their own security purposes in the next 5 years or less.

Presently, students purchasing a monthly, semester, or annual student transit passes, require an OC Transpo Student photo ID card, which can be obtained from OC Transpo Sales and Information Centres where student status can be verified with proper documentation. The $5.00 ID card must be renewed annually and be presented along with the pass upon boarding any transit vehicle. By liaising with the school boards directly, OC Transpo has the opportunity to make the student pass purchasing and validation process much more efficient; all transit pass distribution and student status validation could be offloaded to the schools.

 

In addition to streamlining the student-transit ID issuance process by reducing duplication of effort for both the school boards and OC Transpo, there is also the potential to expand Smart Card use to include other school applications including library and cafeteria services.

 

2.4.3.2  Universities

 

Universities have student ID cards that are similar to those used by area high schools. The University of Ottawa in particular employs magnetic stripe cards that students use for small purchases such as food, gym, and library services. As with the high schools, an opportunity exists to integrate university ID cards with the new transit Smart Card. During our stakeholder meetings, concerns were identified related to the privacy of student information; universities would have to limit what student data is provided to OC Transpo.

 

Under the envisioned transit Smart Card, Universities would distribute student cards with accounts identified only by name. Students could then activate the card at replenishment sites to add value and be able to ride transit. In order to receive pass protection, the card would have to be registered at a valid issuance site, and the student would in turn provide the requisite account information. Under this scenario, the cards would remain the property of Transit Services, and partnership agreements would be established with the school or university in order to issue the cards.

 

An additional consideration is that only full-time students are entitled to the student pass discount on OC Transpo.  If an integrated student-transit card is used, there should be provisions for card deactivation for students that transition to part-time student status after having initially receiving the card as a full-time student. As much as 20% of students begin a semester full-time and end part-time, if there are no deactivation provisions, this 20% of students represents a loss of revenue for OC Transpo (as is the case at present).

 

2.4.3.3  Parking

 

Presently, the City of Ottawa’s Parking Operations has contact Smart Cards for use with certain parking meters. In the future, the transit smart card can be linked to Parking Operations where the transit card could be used to pay for city parking. Also, the transit Smart Card could be accepted at the Park and Ride lots to identify regular transit users and permit entry at discounted or no cost. 

 

2.4.4     Implementation Strategy

 

The City of Ottawa is looking to deploy the Smart Card fare collection system in time for the introduction of LRT service  in the fall of 2009. In general, customers using passes are expected to most readily shift to Smart Cards, ticket users less so (with the remainder shifting to Cash fares), and cash customers least likely to migrate to the new system.

 

The following summarises the implementation strategy for the smart card system that will help migrate over the existing systems and soften the impact on customers:

 

·         Introducing Smart Cards for pass fare products only and keep tickets, cash and transfer printers. At the same time, OC Transpo will phase out existing passes and replace them with smart cards. This will allow OC Transpo to operate and manage the system without having to focus too much effort on getting ticket users to switch to the smart card system;

·         Once the pass strategy is implemented and working,  introduce e-Purse with the LRT expansion and phase out ticket fares. Cash fares and transfer printers will remain. This will allow OC-Transpo customers to softly switch from ticket fares to smart cards; either period passes or e-purse;

·         The OC Transpo smart card system including passes and e-purse products will be acceptable on STO services and visa versa;

·         OC-Transpo may decide at a later stage to expand the smart card system to include certain user markets such as schools and universities as outlined in sections 0.

 

 

 


3.         FUNCTIONAL REQUIREMENTS

 

3.1       Overview

 

This section sets out high-level functional requirements of a Smart Card system for OC Transpo. It follows the system architecture defined in Section 0, and mapping the functional requirements to the relevant tier.

In the following functional requirements, the principal verb is used to indicate a requirement’s priority:

·         shall means that the requirement is mandatory or critical—the requirement must be satisfied by the system;

·         should means that the requirement is desirable;

·         may means that the requirement is optional.

The following functional requirements are grouped and numbered into five tiers as described in section 0, namely; (1) smart cards, (2) acceptance devices, (3) garage and station computer systems, (4) central system and (5) customer service.

3.2             Approach and Assumptions

 

Our approach to define the functional requirements is driven by user needs, operational and business requirements identified in our meetings with OC Transpo’s business units. Appendix A provides notes from these meetings.

 

The definition of functional requirements begins with mapping existing conditions and OC Transpo’s stated business needs with the available technology, influenced by existing and planned Smart Card implementations at other transit properties and related businesses. Our view of both existing conditions and business needs are derived from meetings with representatives of OC Transpo’s business units.

 

These functional requirements assume that relevant provisions of any inter-agency agreement, e.g., with the Société de transport de l’Outaouais will be in place for data exchange and revenue sharing prior to system procurement.

 

3.3       Smart Card Project Objectives

 

In defining the functional requirements, the following objectives are considered:

 

·         The Smart Card system is to be accepted on all OC Transpo buses and at all LRT stations  by June 2009;

·         The Smart Card will be easy to use and understand for customers and staff;

·         The use of Smart Cards will support growth of OC Transpo ridership;

·         Encourage pre-payment of fares;

·         Encourage automated replenishment of smartcard as much as possible;

·         The use of Smart Cards will help in reducing fraud and fare evasion;

·         The use of Smart Cards will reduce OC Transpo’s handling of cash and tickets;

·         The Smart Card will be based on standards, and will not be dependent on particular models of hardware;

·         The smart card system will provide OC Transpo with planning and financial data and reporting capabilities;

·         The Smart Card will build business through synergy with other applications that would be considered in the future.

3.4       Smart Cards

 

This section sets out the functional requirements of the Smart Cards. The numbering system for the Smart Card requirements will proceed with number 1 to map tier 1 in the system architecture description.

 

3.4.1     GENERAL

 

1.1               The Smart Card system shall implement contactless technology for interface between the smart card and readers or other devices;

 

1.2               The Smart Card system shall conform to the applicable laws respecting personal data and information protection;

 

 

1.3               A Smart Card shall be accepted on all OC Transpo revenue services, and wherever OC Transpo transit products or services may be purchased;

 

1.4               Smart Cards shall be issued for three classes of holders:

 

·                     Customers;

·                     Users (i.e., bus operators, fare enforcement officers, customer service staff);

·                     Administrators (i.e., OC Transpo technical and financial staff).

            Unless otherwise specified, the functional requirements specified in this document relate to Customers. Smart Cards for Operators and Administrators are discussed in Section 3.8.13OPERATOR AND ADMINISTRATOR CARDS”, starting on page 43.

 

3.4.2     STANDARDS AND PLATFORMS

 

1.5         All elements of the Smart Card system shall conform to the following standards:

 

1.5.1    Physical standards as defined by:

 

1.5.1.1ISO/IEC 7810, Identification cards—Physical characteristics;

 

1.5.1.2ISO/IEC 7813, Identification cards—Financial transaction cards;

 

1.5.1.3ISO/IEC 7816, Identification cards—Integrated circuit cards.

 

1.5.2    Standards for contactless integrated circuit proximity remote coupling as specified in ISO 14443, Identification cards—Contactless integrated circuit(s) cards, all parts (1 to 4);

 

1.6               No provision of these functional requirements shall cause the medium to deviate from the mandatory provisions of ISO 14443;

 

3.4.3          TECHNICAL REQUIREMENTS

 

1.7               Each Smart Card shall have an on-card operating system capable of performing the functional requirements described here, including card issuance, reloading, transactions, and security;

 

1.8               Each Smart Card shall have on-card memory storage sufficient to support the functional requirements set out in this document;

 

 

1.9               Smart Cards shall form a “family” of cards to support different fare products. All Smart Cards shall conform to the functional requirements set out in this document and shall hold OC Transpo transit products. Different cards in the family may have high or low memory capacities, microprocessors, or dual interfaces; or may be disposable;

 

1.10            Smart Cards shall have a design life of at last five years from issue when subject to ordinary use by a transit customer.

 

3.4.4     FARE PRODUCTS AND DISCOUNTING STRUCTURES

 

3.4.4.1  Period Pass

 

1.11      The Smart Card shall be capable of acting as a Period Pass. A Period Pass permits its Holder unlimited use of specific OC Transpo revenue services during the specified Period;

 

1.12            Without limiting the generality of Requirement 0, the following existing fare products shall be supported by the Smart Card:

 

 

1.       adult regular;

 

2.       adult express;

 

3.       student regular;

 

4.       student express;

 

5.       seniors;

 

6.       annual adult regular;

 

7.       annual adult express;

 

8.       annual student regular;

 

9.       annual student express;

 

10.   rural adult;

 

11.   rural student;

 

12.   student semester regular (fall and winter);

 

13.   student semester express (fall and winter);

 

14.   Ecopass regular;

 

15.   Ecopass express;

 

16.   Ecopass rural.

 

 

1.13             In addition to the existing pass fare products, the smart card shall support transferable passes which may be introduced by OC Transpo in the future;

1.14            The Smart Card shall support a Period that begins and ends on arbitrary dates. It shall also support monthly passes;

1.15            The Smart Card shall be capable of being programmed to apply to specific services (e.g., Rural) and for specific classes of Holders (e.g., Adult, Student, and Senior);

 

3.4.4.2    E-Purse

 

1.16            The Smart Card shall be capable of carrying an E-Purse;

 

1.17            An E-Purse shall hold value, denominated in Canadian dollars, for its Holder to purchase OC Transpo fares;

 

1.18            Discounted fares should be considered for E-purse users;

 

1.19            An E-Purse may be used to purchase other services or products of OC Transport or the City of Ottawa.

 

3.4.5          OTHER SUPPORTED APPLICATIONS

 

1.20            The Smart Card should be usable on regular bus routes of the Société de transport de l’Outaouais;

 

1.21            The Smart Card should support, or be capable of supporting, applications other than customer use of OC Transpo services. Without limiting the generality of this requirement, such applications shall include:

 

1                     identifying OC Transpo or City of Ottawa employees;

2                     permitting access to buildings or specific parts of buildings owned or used by OC Transpo or the City of Ottawa;

3                     permitting access to buildings/facilities of other agencies where other applications are supported by the OC Transpo card;

4                     integration with other public- or private-sector smart-card applications, such as student cards.

1.22            A Smart Card should be capable of being issued with additional products loaded on it, such as Park & Ride programme.

 

3.4.6          CARD GRAPHICS AND SERIALIZATION

 

3.4.6.1  Serialization

 

1.23            Every Smart Card shall bear a unique serial number. This serial number shall both be encoded in the card chip and visible on the card.

 

3.4.6.2    Branding and Graphics

 

1.24            The Smart Card shall be branded by OC Transpo. This branding shall include a name for the medium (i.e., not necessarily Smart Card) that the consumer may understand is linked with particular functions and constraints;

 

1.25            The Smart Card shall be able to bear graphics and logos on both sides;

 

1.26            The Smart Card may be able to bear other graphics for advertisement purposes;

 

3.4.7          ISSUANCE, PERSONALIZATION, REGISTRATION, UPDATING, AND REPLENISHMENT

 

See also Section 0

Customer Service Systems”, starting on page 36.

 

3.4.7.1    Issuance

 

1.27            Smart Cards shall be issued by OC Transpo or third party authorised by OC Transpo.

 

3.4.7.2    Personalization

 

1.28            Each Smart Card that is issued as a Period Pass shall be Personalized, the effect of which shall be to associate each Smart Card with one and only one unique Holder;

 

1.29            Should  transferable passes be adopted in the future, they shall be  exempted from the above requirement;

 

1.30            Each Smart Card shall be Personalized by:

1.30.1      storing on the card a minimum data set of personal information about the Holder;

1.30.2      printing a picture of the Holder (and other information) on the card.

 

1.31            The minimum data set called for in Requirement 1.30.1 shall be sufficient that an OC Transpo employee shall be able to confirm that a person using a Smart Card is indeed the Holder.

 

3.4.7.3    Registration

 

1.32            Holder shall be able to register their Smart Card;

 

1.33            Registration shall connect the Smart Card to an Account in the central system, and the Account to the Holder, thus permitting OC Transpo to refund the value on a Registered Smart Card (if smart card is reported lost, stolen or malfunctioned).

 

3.4.7.4    Updating

 

1.34            Information stored on the Smart Card shall be capable of being updated; that is, information on the card about the Holder and his or her Account may be changed;

 

1.35            Notwithstanding Requirement 1.34, a card issued with period pass product shall not be transferable to another Holder.

 

3.4.8          CARD REPLENISHMENT

 

1.36            The Smart Card shall be capable of being replenished. That is:

 

1.36.1      a Period Pass shall be capable of being renewed for at least one period;

 

1.36.2      an E-Purse shall be capable of having more value added to it.

 

3.4.9          SECURITY PROVISIONS

 

1.37            During personalization, each Smart Card shall be encoded so that acceptance and customer-service devices recognize that the card was Personalized by a device authorized by OC Transpo;

 

1.38            The Smart Card shall not allow any physical modifications, e.g., having the Holder’s ID picture replaced;

 

1.39            The Smart Card’s on-board chip shall be tamper proof for any modification by a non-authorized device.

 

3.5             Acceptance Devices

 

This section presents functional requirements for the devices that accept the Smart Card: on-bus readers; station validators; ticket vending machines; and handheld readers.

 

3.5.1          VALIDITY OF ACCEPTED MEDIA

 

Except where otherwise specified, the requirements in this section apply only to a valid Smart Card.

 

A Smart Card is valid:

 

·         if it is carrying a Period Pass and the Period to which it applies has begun and not ended; or

·         if it is carrying an E-Purse and the value extracted from the E-Purse by the acceptance device does not reduce the value remaining on the card below zero. However, OC Transpo may consider allowing cards to go below zero balance, up to a maximum equivalent to full adult cash fare, and having the money paid back when the card is next replenished;

·         If the smart card is not reported as lost, stolen or blocked.

3.5.2          GENERAL

 

These requirements apply to all smart card readers. The numbering system for the Acceptance Devices functional requirements will start with number 2 to map tier 2 in the system architecture description.

 

2.1               A reader shall be capable of reading and processing all OC Transpo Smart Cards;

 

2.2               A reader should be capable of reading and processing smart cards issued by the Société de transport de l’Outaouais;

 

2.3               A reader shall be capable of reading ISO 14443–compliant cards, both Type A and Type B;

 

2.4               A reader shall have memory storage and processing power sufficient to perform the functions specified for it for at least seven days without communication with garage or station computer systems;

 

2.5               A reader shall be capable to write data on the card sufficient to allow electronic transfers and fare inspection

 

2.6               A reader shall be capable of meeting security requirements and requirements for authentication.

 

3.5.3          ON-BUS READERS

 

2.7               An on-bus reader shall comprise: a Fare Transaction Processor (FTP); a Driver Display Unit (DDU); and a Customer Display Unit (CDU). The functions of the Driver Display Unit should be carried out by the SmartBus Mobile Data Terminal;

 

2.8               An on-bus reader shall query both the information stored on the card and the information stored in its database to determine if the Smart Card is valid for admittance to the transit service;

 

2.9               An on-bus reader shall perform the functions specified for it locally without communication with a central system;

 

2.10            An on-bus reader shall decrement a Smart Card E-Purse’s stored value by the amount equivalent to the fare value, if that is appropriate to the fare class, and shall record a transaction to its database for later uploading;

 

2.11            An on-bus reader shall positively indicate (e.g. by visual and audio tone) to the operator and bearer that the Smart Card is valid for admittance to the transit service. This positive indication should be displayed on the DDU and CDU;

 

2.12            An on-bus reader shall indicate to the operator, and should indicate to the customer, the reason the Smart Card is determined invalid for admittance to the transit service. The reason for non-admittance may be displayed so that no one other than operator or attendant and bearer can see it. All messages to customers shall be in both French and English languages;

 

2.13            An on-bus reader shall display the information stored on the card about the card’s value, e.g., the Period(s) to which its Period Pass applies; and the cash value remaining in the E-Purse;

2.14            An on-bus reader shall be capable of downloading and storing information about Smart Cards in circulation through network communication with the garage computer system. This information:

 

2.14.1      shall include a list of Blocked cards’ serial numbers and any other associated data;

2.14.2      shall include a list of Suspended cards’ serial numbers and any other associated data;

2.14.3      should include information sufficient to update cards when the cards to be updated are presented to the reader;

 

2.15            An on-bus reader shall be capable of downloading and storing through communication with garage systems, fare tables, software upgrades and other data;

 

2.16             Readers whose functions are specified in this section shall be supported by and integrated in the SmartBus services including interface to the MDT and on-board Smart Bus system.

2.17            The size, dimension and mounting of on-bus readers shall not restrict operators sight or disturb them from driving;

 

3.5.4          STATION VALIDATORS

 

This section defines functional requirements for stand-alone station validators or smart card modules to be installed and integrated with LRT fare collection system. 

 

3.5.4.1    General

 

2.18            A station validator shall query both the information stored on the card and the information stored in its database to perform the functions specified in this section;

 

2.19            A station validator shall be able to perform the functions specified for it in a degraded mode (limited or no communication with the central system) for at least seven days;

 

2.20            A station validator shall record details of its transactions in its database;

 

2.21            A station validator shall be capable of accessing information about Smart Cards in circulation through network communication with the station computer system. This information:

 

2.21.1      shall include a list of Blocked cards’ serial numbers;

 

2.21.2      shall include a list of Suspended cards’ serial numbers;

 

2.21.3      should include information sufficient to update cards when the cards to be updated are presented.

 

3.5.4.2    Validation of a Smart Card with e-Purse

 

2.22            When a Smart Card without a Period Pass is presented to it, a station validator shall:

 

2.22.1      decrement a Smart Card E-Purse by the cost of the fare stored on the card;

 

2.22.2      record on the card when and for what fare product the E-Purse was charged.

2.23            If the value in the E-Purse is not sufficient for the fare indicated by the bearer, the validator shall:

 

2.23.1      indicate so;

 

2.23.2      abort the validation process described in Requirement 2.22.

 

2.24            A station validator shall positively indicate to the bearer:

 

2.24.1      whether or not the Smart Card is valid for passage at the selected fare;

 

2.24.2      the value remaining in the E-Purse;

 

2.24.3      if appropriate, the reason the Smart Card was found invalid for passage.

 

3.5.4.3    Validation of a Smart Card with a Period Pass

 

2.25            When a Smart Card with a Period Pass is presented to it, a station validator shall:

 

2.25.1      check validity of the card against hot (or black) list;

 

2.25.2      check time validity of the pass.

 

2.26            A station validator shall positively indicate to the bearer:

 

2.26.1      whether or not the Smart Card is valid for passage;

 

2.26.2      if appropriate, the reason the Smart Card was found invalid for passage;

 

2.26.3      OC Transpo may decide to continue to give a day grace on monthly passes.

 

3.5.5          HAND-HELD INSPECTION DEVICES

 

2.27            A handheld device shall be used by fare inspectors to verify smart card payments, transfers or pass validity;

 

2.28            A handheld equipment shall be able to query about previous warnings and offence notices issued by fare inspectors;

 

2.29            A Smart Card issued by OC Transpo or STO shall be readable by a hand-held inspection device;

 

2.30            A hand-held inspection device shall display as a minimum the following information:

 

2.30.1      information stored on the card by on-bus readers and station validators;

 

2.30.2      information stored on the card about the fare product, e.g., the Period(s) to which its Period Pass applies; and the value remaining in the E-Purse.

 

2.31            A hand-held inspection device should query its database (including black lists) to determine if the Smart Card is valid for a transit service;

 

2.32            A hand-held inspection device should not display personal information about the Holder in a manner visible to anyone other than the operator or attendant and the Holder;

 

2.33            A hand-held inspection device shall not alter the information stored on the card;

 

2.34            A hand-held inspection device should be capable of downloading and storing information about Smart Cards in circulation. This information shall include a list of Blocked cards’ serial numbers, and may include detailed information on Accounts;

 

2.35            A handheld device shall be of minimum size and weight to perform the above mentioned functions by fare inspectors.

 

2.36            The range of coverage for handheld devices will be sufficient to make it easy for fare inspector to read the cards.

 

3.6             Garage and Station Computer Systems

 

This section presents functional requirements for the garage computer system (for bus transit services) and station computer system (for LRT lines services).

The numbering system for the Garage and Station Computer Systems requirements will start with number 3 to map tier 3 in the system architecture description.

 

3.6.1          GARAGE COMPUTER SYSTEM

 

3.1               The garage computer system shall communicate with the on-bus readers at the countdown maintenance process through a Wireless Local Area Network (WLAN) that is compliant with IEEE Standards 802.11;

 

3.2               The wireless network shall be secured and have encryption enabled;

 

3.3               The wireless network shall require authentication of its client devices before they can access the network;

 

3.4               The garage computer system shall:

 

3.4.1          download data from the central system to the on-bus readers;

 

3.4.2          upload data from the on-bus readers to the Central System.

 

3.5               The data the garage system downloads from the Central System and uploads to the on-bus readers:

 

3.5.1          shall include a list of blocked cards’ serial numbers;

 

3.5.2          shall include any updates or revised software;

 

3.5.3          should include information sufficient to update cards when the cards to be updated are presented;

 

3.5.4          may include detailed information on accounts.

 

3.6               The data the garage system downloads from the on-bus reader and uploads to the Central System shall include records of all transactions at the reader, including reader identity, transaction type (validation, invalidation, rejection by cause, etc.), Smart Card identity, fare class, and date and time.

 

3.7               The garage computer system hardware shall have the memory storage and processing power capable to perform the functions required by the system.

3.6.2          STATION SYSTEM

 

3.8               The station computer system shall communicate with the station devices via wired or wireless Local Area Network (LAN or WLAN) that is compliant with IEEE Standards 802.11;

 

3.9               Any WLAN shall be secured and have encryption enabled;

 

3.10            The LAN shall require authentication of its client devices before they can access the network.

 

3.11            The station computer system shall:

 

3.11.1      download data from the Central System to the station devices;

 

3.11.2      upload data from the station devices to the Central System.

 

3.12            The data which the station computer system downloads from the Central System and uploads to the station devices:

 

3.12.1      shall include a list of Blocked cards’ serial numbers;

 

3.12.2      should include information sufficient to update cards when the cards to be updated are presented;

 

3.12.3      may include detailed information on accounts.

 

3.13            The data which the station computer system downloads from the station devices and uploads to the Central System shall include records of all transactions at the validators and ticket vending machines, including device identity, transaction type (validation, invalidation, rejection by cause, etc.), Smart Card identity, fare class, and date and time;

 

3.14            The station computer system hardware shall have the memory storage and processing power capable to perform the functions required by the system.

 

3.7             Central System

 

This section presents functional requirements for the central system.

 

The numbering system for the requirements will start with number 4 to map tier 4 in the system architecture description.

 

4.1               The central system shall form the data processing and revenue management functions and reporting for the smart card system;

 

4.2               The Central System shall upload every Smart Card–related transaction carried out from front-end (Tier 2 and 3) and customer-service (Tier 5) devices;

 

4.3               The Central System shall reconcile all transactions, and shall update Accounts, on a continuous basis;

 

4.4               The Central System shall download lists of Smart Cards that are Blocked to front-end (Tier 2 and 3) and customer-service (Tier 5) devices. (Depending on the software design, unblocking transactions may be included in these block lists.);

 

4.5               The Central System shall download information sufficient to update Smart Cards when they are next presented to front-end (Tier 2 and 3) and customer-service (Tier 5) devices;

 

4.6               The Central System may download detailed account information to front-end (Tier 2 and 3) and customer-service (Tier 5) devices;

 

4.7               The Central System shall provide financial information for OC Transpo’s financial accounting system (general ledger). The frequency and format of the Central System’s postings to the general ledger are to be specified;

 

4.8               The Central System shall produce management and operational reports for OC Transpo. The content, frequency, automation, and audience of these reports are to be specified. Consideration should be given to providing OC Transpo with a reporting environment rather than a suite of fully or partially hard-coded report;

 

4.9               The Central System shall permit on-line query of major parameters at any time. The Central System shall permit on-line query of daily, weekly, and monthly summary data. This requirement may be combined with Requirement 4.7 in a reporting environment;

 

4.10            The Central System shall be integrated with OC Transpo’s bank for the purposes of credit-card authorization, debit-card authorization, and pre-approved chequing transactions;

 

4.11            A minimum level of data exchange of smart card hot list between OC Transpo and STO shall be provided;

 

4.12            The Central System shall be integrated with OC Transpo finance reporting and auditing system SAP;

 

4.13            The Central System shall provide interfaces to the Paratranspo payment system;

 

4.14            A minimum level of e-purse transactions of smart cards issued by STO and accepted by OC Transpo shall be exchanged with STO Central System and visa versa.

 

3.8             Customer Service Systems

 

This section presents functional requirements for the customer service systems.

 

The numbering system for the requirements will start with number 5 to map tier 5 in the system architecture description.

 

3.8.1          GENERAL

 

5.1               OC Transpo shall establish a customer service function to support the Smart Card system;

 

5.2               The customer service function shall support receiving and fulfilling requests for customer service:

 

5.2.1          by walk up to a Smart Card Full-Service Centre;

 

5.2.2          by telephone, i.e., to a call centre IVR;

 

5.2.3          at a service kiosk or ticket vending machine;

 

 

5.2.4          through the Smart Card Web site;

 

5.2.5          by walk up to a third-party outlet.

 

5.3               These requests for customer service shall be supported:

 

5.3.1          to issue a Personalized Smart Card (Period Pass or E-Purse or both;

 

5.3.2          to issue a non-Personalized Smart Card (E-Purse only);

 

5.3.3          to register a Smart Card;

 

5.3.4          to reissue a Smart Card (e.g., when initial card lost or stolen);

 

5.3.5          to replenish a Smart Card (i.e., to roll over a Period Pass or top up an E-Purse);

 

5.3.6          to initiate or terminate a pre-authorized roll-over or top-up;

 

5.3.7          to block a Smart Card (e.g., because it’s been lost or stolen);

 

5.3.8          to accept surrender of a Smart Card;

 

5.3.9          to refund a Smart Card (Period Pass or  E-Purse or both);

 

5.3.10      to answer queries about an Account.

 

5.4               All customer service locations shall accept payment from customers as specified in Requirement 5.5.

 

5.5               Requests for customer service shall be supported at the locations shown in the following table. In this table:

 

·         M (for mandatory) indicates that the function shall be supported at the location;

·         O (for optional) indicates that the function should be supported at the location;

·         D (for desirable) indicates that the function may be supported at the location;

·         -” indicates that the function shall not be supported at the location.




 


full-service centre

call centre[2]

kiosk or TVM

Web

3rd-party centre[3]

issue Personalized

M

-

-

-

-

issue non-Personalized

M

M

-

M

M

Register

M

-

-

M

-

Reissue

M

M

-

M

-

replenish

M

M

M

M

M

replenish (pre-authorization)

M

M

-

M

-

blocking/reporting

M

M

-

M

-

surrender

M

D

-

-

-

refunding

M

-

-

-

-

queries

M

M

D

M

D

accept payment

M

M

M

M

M

 

3.8.2          ISSUING A PERSONALIZED SMART CARD

 

See Section 3.4.7.2Personalization”, page 29, for the requirements associated with personalization of a Smart Card.

 

5.6               A Personalized Smart Card acting as a Period Pass shall be issued for a particular class of service (e.g., Rural) and for a particular class of Holder (e.g., Senior).

 

5.7               A Personalized Smart Card acting as a Period Pass shall be issued for a particular period. However, the beginning and ending dates shall not be constrained by the Smart Card system.

 

5.8               At the customer service location:

 

5.8.1          payment of the published fee for a Personalized Smart Card plus fees for the requested Period Pass and E-Purse value shall be received;[4]

 

5.8.2          personalization information shall be gathered from the prospective Holder;[5]

 

5.8.3          the identity and fare class of the Holder shall be verified by comparison with other documents;[6]

 

5.8.4          a digital picture of the Holder shall be taken;

 

5.8.5          some of the personal information shall be stored on the card;

 

5.8.6          the picture of the Holder shall be printed on the card (for period pass fare products);

 

5.8.7          the card shall be programmed with the paid-for Period Pass;

 

5.8.8          the card shall be issued to the Holder.

 

5.9               Purchase of a Personalized Smart Card by someone other than the Holder shall not be accommodated.

 

3.8.3          ISSUING A NON-PERSONALIZED SMART CARD

 

5.10            At the customer service location:

 

5.10.1      payment of the published fee for a non-Personalized Smart Card plus fees for the requested E-Purse value shall be received;4

 

5.10.2      the card shall be programmed with the paid-for E-Purse;

 

5.10.3      the card shall be issued to the customer.

 

3.8.4          REGISTERING A SMART CARD

 

5.11            Registering a Smart Card shall associate the physical Smart Card medium (including its personalization, if any, and its unique serialization) with an Account in the Central System’s Central System.

 

5.12            The Account shall comprise material information about the Holder and the services, period, E-Purse value, and other information about the Smart Card.

 

5.13            At the customer service location:

 

5.13.1      payment of the published fee for registering a Smart Card shall be received;4

 

5.13.2      personal information shall be gathered from the prospective Registrant;5

 

5.13.3      a registration transaction shall be queued for uploading to the Central System.

 

5.14            Registration of a Personalized Smart Card by someone other than the Holder or an authorized agent of the Holder should not be accommodated.[7]

 

3.8.5          REISSUING A SMART CARD

 

5.15            OC Transpo shall reissue a registered Smart Card at the request of its Registrant;

 

5.16            OC Transpo shall not reissue a non-registered Smart Card;

 

5.17            At the customer service location:

 

5.17.1      payment of the published fee for reissuing a Smart Card shall be received;[8]

 

5.17.2      the identify of the Registrant, or the person authorized to act for the Registrant, shall be verified;5

 

5.17.3      the registered Smart Card previously associated with the Account shall be permanently Blocked;

 

5.17.4      as applicable, the personalization information, Period Pass, and E-Pass value shall be programmed in the new card;

 

5.17.5      if applicable, the Holder’s picture shall be printed on the new card;

 

5.17.6      the new Smart Card shall be issued to the Holder.

 

3.8.6          REPLENISHING A SMART CARD

 

3.8.6.1    One-off Replenishment

 

5.18            A customer shall be able to replenish a Smart Card by offering payment for this replenishment. More specifically:

 

5.18.1      The customer shall be able to extend the Period Pass on the card by one or more periods; or

 

5.18.2      The customer shall be able to add value to the E-Purse on the card.

 

5.19            A customer should be able to replenish a Smart Card at a time of the consumer’s choice. E.g., a customer may extend a Period Pass one month on the last day of month (or earlier) in which the Period Pass expires.

 

5.20            At the customer service location:

 

5.20.1      payment of the published fee for the extension of the Period Pass or the requested E-Purse value shall be received;4

 

5.20.2      the card shall be programmed with the new Period(s) or the new value of the E-Purse;

 

5.20.3      if the card is Registered, and update to the Account associated with the card shall be queued for uploading to the Central System.

 

3.8.6.2  Automatic Replenishment

 
3.8.6.2.l   Initiation

 

5.21            A customer should be able to have a Registered Smart Card replenished automatically, as specified in this section;

 

5.22            A customer should be able to pre-authorize payment for rollover of a Period Pass or top-up of an E-Purse, i.e., by automatically charging a credit card or debiting a bank account;

 

5.23            A customer should be able to specify constraints on rollover of a Smart Card Period Pass. Without limiting the generality of this requirement, a customer should be able to specify that only a certain number of rollovers are to be made;

 

5.24            A customer should be able to pre-authorize replenishment of an E-Purse when the value contained in the E-Purse falls below a level specified by or agreed to by the customer;

5.25            A customer should be able to specify constraints on the pre-authorized replenishment of a Smart Card. Without limiting the generality of