Ebook Dual Interface Smart Card Reader
An estimated 200 million people use public transport worldwide. It is the preferred mode of transport throughout much of Asia and Europe. Every day over 65,000 people use public transport to commute to work in New Zealand. Since 2000 its use has grown 7.5% each year in this country. It is perceived as a cost effective, environmentally friendly alternative to private transport. Another advantage that public transport operators are striving to promote is that of convenience. Part of this challenge is embodied in public transport ticketing.
Ease of use, as required by the customer, includes simplistic methods for ticket purchase, verification and value adding in the case of reusable tickets. Verification processes usually occur at the point of boarding the transportation, whilst value adding has traditionally been conducted at ticketing agents. The needs of the operators include ticket security, data collection and the prevention of fraud, such as ‘over-riding’ or ‘crowding-in’.
Since most users of public transport are regular customers, tickets that can store transport credit have been adopted almost universally. Over the past decade smart cards have become the technology of choice in transport ticketing. This is because smart cards offer the following advantages over traditional paper and magnetic stripe ticketing means:
- Increased data storage capacity
- Issue, verify and top-up process automation
- Ticket security through encryption of sensitive data to reduce counterfeit/fraud.
- Relatively fast customer processing speeds (less than 5 seconds) at point of boarding.
- Long life (over 10,000 transactions)
- Adaptable to new applications
- Multiple applications can be integrated on one card
- Standard credit card size (as per ISO 7810)
- Advertising area on both sides of the card
Despite these qualities, a problem exists in the supporting process of adding value to smart cards. The queues for bus card value adding in the University of Auckland quad are a case in point. Value adding is possible on most buses, but the transactions are slow and often involve cumbersome amounts of money. These transactions have been displaced to ticketing agents or retailers because they are often paid for by EFTPOS, which is unavailable on buses. As an incentive, a discount is offered to students who purchase from the agent located within the university quad. Most weeks, especially at the beginning of university terms, there are lines of up to 50 students waiting to purchase ticketing products from this vendor. A university magazine article about the problem reported that some customers wait over 30 minutes to be served.
This problem could be attributed to several things, the first of which is the transaction processing time. Currently a counter attendant must process the payment and then the bus card transactions on separate hardware. The payment method is often EFTPOS, which is a major factor in total transaction time. The second attributing factor is the incidence of purchasers entering the queue. The structured lecture timetable conducted by the University matches the trend of increased demand on the hour and at lunchtimes. While this could be seen as a mass behavioural flaw, these phenomena may well be induced by a combination of the opening hours of the agent and student coursework commitments.
A number of solutions to the value adding problem were considered. The best proposition was on bus top up, whereby prepaid value could be added to the card when the user presents their card upon boarding a bus. Such a system requires a sophisticated back end that could render the scheme infeasible. The term ‘back end’ is used in this report to refer to those components of a system that carry out data handling and which are often hidden from the user. Hence back end distribution of the prepaid ticket information to all buses in real time presents a considerable technical challenge. Whilst the ‘all buses’ and ‘real time’ conditions could be relaxed somewhat, the fact remains that such a system would require a significant technical upgrade to existing ticketing equipment and infrastructure. Although decidedly the most convenient solution for customers, this was seen as an impractical goal for a fourth year project.
A second discarded solution was that of a ticketing kiosk, at which students could insert their bus card and make payment for value via cash or EFTPOS. This method offers efficiency gains by automating and integrating the payment and value adding processes. A secondary advantage might be that the kiosk could be kept open 24 hours per day. The disadvantage is that the EFTPOS terminal will still take the same long processing times, and the terminal itself will be subject to rigorous security standards. The cash alternative entails the expensive business of cash handling and sensitive metering requirements, not to mention the security concern of theft. These two payment methods were seen as presenting non-technical, bureaucratic difficulties that could not be reconciled with the requirements of a fourth year project in electrical engineering.
Elements of the first and second solutions were combined into the eventual context of the project. Similar to the on bus top up, users can prepay for value and collect it on their card later. As with the kiosk, it is a solution that enables users to do the transaction anytime. The prepay purchase is designed to be made from a back end system connected to a stand-alone hardware unit, located centrally, for value transfer to cards. The hardware unit was the focus of this project. The major goal was the implementation of a demonstration system without the back end processing.
Section two gives a broad, historical background of smart cards and transport ticketing, while Section three describes the proposed solution to the value adding problem and the project objectives in more detail. Sections four through seven describe the hardware and firmware components where project work was focused. The eighth Section offers some recommendations for future work on the project, while Section nine outlines the conclusions drawn from the work completed.
Contents
Glossary of Terms
1 Introduction
2 Background
3 Project Context
- 3.1 Bus Card Value Adding System
3.1.1 Functional Specification
3.1.2 Reader Block Diagram
3.2 Project Scope
3.3 Division of Work
4 Host Microcontroller
4.1 Selection Criteria
4.2 Development Board
5 Contact Card Interface
5.1 Contact Cards
5.2 Reader Selection
5.3 Interfacing the GemCore410
- 5.3.1 Communication Protocol Structure
5.3.2 Transport Layer Protocols
5.4 Firmware Development
- 5.4.1 PC Host running Windows using the GILK
5.4.2 PC Host running Windows using the GILK
5.4.3 Microcontroller Host using the GILK
5.4.4 Microcontroller Host using Assembly Language
6 Contactless Card Interface
6.1 Contactless Cards
6.2 Reader Selection
6.3 PCB Design
6.4 Firmware Development
6.5 Evaluation Kit
7 Peripherals
7.1 User Interface
7.2 Memory Buffer
7.3 Server Interface
8 Future Recommendations
9 Conclusions
10 References
11 Bibliography
Appendix 1 – PCB artwork for Micro Development Board
Appendix 2a - 8051 Flash Microcontroller Comparison Table
Appendix 2b – Contact Smart Card Interface Products
Appendix 2c – Contactless Smart Card Interface Products
Appendix 3a - GemCore Interface Library Kit (GILK): Original physical layer header file [PP.h]
Appendix 3b - PC-host: Altered GILK physical layer [PP.c]
Appendix 3c - Micro-host: Altered GILK physical layer [PP.c]
Appendix 3d - Micro-host: Critical elements of GILK [TLP224.c]
Appendix 3e - Micro-host: Custom example program [TLPhack.c]
Appendix 3f - Micro-host: Final assembly language program [GemCore.asm]
Posted in :
