For those interested in the OC Transpo implementation of the Presto Smartcard:
In November 2007, Ottawa City Council approved participation in the Presto smartcard system. A limited Ottawa field test is planned for the fall of 2010 and city-wide implementation is planned for winter of 2011.
Municipalities surrounding Toronto will begin trials in September of 2009.
The TTC has not yet signed on to Presto, but is expected to once all the bugs are worked out of the system.
The current thinking/planning as I understand it:
- It is recommended that the card NOT require an accompanying ID photo. This makes the card transferable, although it might be declared as “NON-Transferable”, similar to paper transfers now. Declaring the pass as non-transferable will likely have little effect since there will be no way to enforce that rule. It is also possible that it will be a transferable or ‘transfer-permitted’ pass. If so, a parent might buy a pass for work, but the children could use it during evenings and week-ends. Also, assuming no U-Pass, the University of Ottawa Student Union could buy 100 passes and divide them between the Main and Lees Campuses, allowing students to use the shared passes to shuttle between classes.
- The Presto card can be concurrently configured as a Pass AND as a Purse. This will allow people to have extra stored money on their pass to pay for Express Top-ups, or to pay for accompanying riders. For example, a parent could have a card which functions as their monthly pass, but also can be used to pay for an extra child’s fare when they go to the museum on the week-end. In this case, the default transaction use of the card is as a Pass with Operator assistance required to have an additional, separate fare deducted from the Purse. There is no requirement to have both functions; the card could simply be a Pass OR a Purse.
- The card’s Purse can, optionally, be configured to have an automatic re-load of value. It is currently thought that a minimum value of $10 can be added to the card. There has not yet been a determined re-load point or minimum stored value on the card, and this might be a user configurable thing. For example, one person might want to re-load whenever the stored value drops below $10, while another person might be happy with $1 left before re-loading their card. If the card is set-up with the optional re-load feature, then the card will be able to go into debt, or hold a negative balance, until it is re-loaded that evening. The re-load requirement will be calculated by the main system after the nightly up-load of bus data. For example, if a person took three rides using a card which only had enough value for two rides, the third ride would cause the card to store a negative value, but would not be barred due to insufficient funds. Once the data from the three buses was up-loaded, the main database would be updated with each ride taken, in chronological order, based on the time-stamps of the rides. At the point that the re-load point is reached, the new funds will be transferred in and the updating continued. This will cause the database to have a different value than that stored on the card, thus the card is added to the ‘Changed’ list.
- The main card database is held off-line, but every night, every bus will be updated with a list of “Black-listed” cards, and a list of Changed cards. Black-listed cards are cards which will not be honoured on the buses; changed cards are those which have had their expiration date or value altered. The first time a card on the Changed list is used, the card will be updated from the bus’s information. For example, if a card’s value was re-loaded over night, the next morning, the card’s negative value will be replaced with the database value before the new transaction is processed. The same happens if the expiry date has changed, or any other information. In fact, the same process could be used for black-listed cards also, by simply changing the expiry date to a past date and zeroing the value.
STO cards will be included in the database which is down-loaded to the buses so that black-listed and changes STO cards can also be handled.
The same functions will need to be performed by the HCR (Hand-held Card Readers) that the Fare Inspectors use, since any changes to the card’s values must be updated before its validity can be ascertained. The HCR should not, however, need to do any processing itself, so it need not store any transaction records and should not be required to up-load any data to the main database.
- Every transaction is recorded to the bus’s databases and the last five transactions are stored on the card. These records are used to determine if the card has already been updated, if a transfer is within the time limit, etc., and are up-loaded nightly to the main database. Fare Inspectors, with their HCRs, will have access to the history of the last five trips taken with the card; this might be required if when the check is done the transfer time has expired, but the current bus was boarded within the time limit. In this case, the Inspector will need to manually calculate if the last boarding time was within the allotted time. I don’t know if this will cause trouble.
Additionally, there might be privacy issues about the Fare Inspector having access to the last five boarding records. It might be possible for these records to span many hours or days: I suggest that the records displayed be restricted to only those which might be applicable to validating the specific ride.
- The total time of the boarding transaction is to be less than 300 milliseconds. This time will include the card power-up time; hand-shaking and presentation of the card’s number and other data to the bus; the bus validating the card and its data; re-loading the card data if required; passing the card the amount to be deducted; waiting for and getting the card’s acknowledgment; storing the transaction record on the bus and on the card; and lighting the appropriate light and sounding the tone.
A green light and ‘happy’ tone will accompany a successful transaction; a red light and ‘attention-getting’ tone for a refusal; and a yellow light will be presented with the ‘attention-getting’ tone if there is a technical problem with the transaction. I believe the Operator will be able to over-ride the system, thus, if a person is denied boarding onto an Express Bus because they have their Presto card configured as a Regular Pass with no Purse, the Operator can let them on with a cash top-up. I expect that such a transaction is recorded as a fail with Operator intervention. The passenger would require a paper transfer/POP.
- Multiple fares can be removed from the Purse on one boarding, as when one person pays for several friends, only with Operator assistance. Under normal operation, only one fare will be removed for the duration of the transfer time. This will allay the fear that a card’s value might be drained by standing too close to the reader.
However, I am not sure if a transaction record is stored with each of those card-reads. It might be that the same bus will not record a transaction from the same card within the transfer period. This has a potential drawback of not recording some ‘stop-overs’; where a person leaves a bus to do some shopping on the way home, and happens to catch the same physical bus on its next pass, but still within the time limit, to complete the journey home. This might not be a significant problem, though, as it will probably be a rare case and missing those records might be inconsequential.
- Registration of the Presto card might be optional, but registration provides insurance against card loss, since a registered card can be replaced with its database value transferred to the new card. No personal data is stored on the card, and is only in the main database if it is supplied during registration. Any personal data stored is used solely to provide identification for the insurance function.
- Money paid for passes is immediately transferred to OC Transpo by Presto, less a 1% administration fee, while money loaded into Purses is held by Presto and transferred to OC Transpo as it is spent, less 1%. Any interest accrued on the Purse amounts is divvied up and returned to the member transit companies; I don’t know if this too is subject to the 1% fee. A 1% fee is what OC Transpo currently pays to ticket and pass venders. I also don’t know if the network of venders will be abandoned, leaving only OC Transpo outlets as the sole source of the cards. From what I heard, OC Transpo is hoping to save money by not issuing paper passes and tickets, and is expecting to be able to reduce the staffing and real estate requirements at their own outlets due to a smaller month-end demand bulge. If OC Transpo outlets become the only places to get the Presto cards, there might not be a drop in the required customer relations staff. The cost of the physical Presto card will be recaptured by charging $5 for the cards.
- In an effort to maintain the ‘status quo’, the Pass card rules will be as similar as practical to the current pass rules. Thus, the next month’s pass can be purchased after the 20th of the month, and only one extra month can be purchased at a time. Restrictions as to what types of buses can be boarded will also apply, based on what type of Presto Pass was purchased, with cash top-ups required to ride the more expensive routes.
I find it curious that there will be such restrictions on pre-purchasing passes, or purchasing passes of specific durations. It looks as if the pass expiry date is determined by a stored date in the database and is not linked to a particular month by name. For example, if a month is purchased, the date is set to the last date of the month; for a semester pass, that date is the end of the semester; and annual passes terminate with the year. Since the expiry date can be set to any date, why is there an arbitrary restriction on what can be purchased? A contract worker might want to purchase a pass for a three month contract: A company might want to have a foreign worker live and work in Ottawa for a six month period and would like to supply a Presto card covering that period: A convention or sports group might want to supply passes to their members for the two weeks they are in town: Tourists might want to purchase a 3-day or 5-day pass to tour the city’s sights. All of these options are possible, but are currently rejected because they don’t match what we currently sell as paper passes.
- The current budget of $21M accounts for readers only at the front doors of the buses. It would be possible to add readers at all doors, but that would mean dive per Arctic, since the rear doors are double width. It would get very expensive. Thus, people with Purse passes will be required to board by the front door, even when they are transferring, similar to today with paper transfers.
OC Transpo's unofficial motto "We are all for radical change, as long as the system is the same in the end."
Heck yeah, we want to change to Smartcards - as long as they can emulate our current paper pass, ticket, and transfer system.
Heck yeah, we want to change to LRT - as long as it follows our current routes and we can still use our buses.
Prev
Linear Mode
