Smart-card validator and display


Description/objectives

Smartcard validators are part of the fare collection system. They are machines that ‘read’ smartcards and support the fare applications contained on them.

On-board validator units can be contact, contactless or both, and can be stand-alone or integrated with the on-board computer. All unit types tend to include an embedded processor and information storage capability. Embedded memory can store up to 60,000 transaction records and can be downloaded via USB, wireless LAN or GSM/GPRS. Integrated units transmit data through any of these methods and receive location information from the AVL system via connection to the on-board computer. Stand-alone systems can have embedded GPS cards to provide location information and embedded GSM/GPRS or wireless LAN devices. Turnstile validators have internal memory and processor and are generally connected to a central computer system (from which fare information is downloaded) via wireless LAN or Ethernet connection.

Smartcard validators are usually located at stations or stops, or on vehicles. The functionality of the validator unit usually varies depending on the location of the unit. For example, on-board validators, or those located at turnstiles, do not tend to provide top-up services (although compact top-up capable units are available) and generally have a simplified monochrome display. These simplified units can display the passenger’s journey information, ticket status (validity/expiry date/value) and a real-time clock. These units also have a traffic light type LED display to indicate transaction success. Audio capability is also usually provided, with a sound emitted to accompany the LED display as well as a buzzer/speaker facility for passenger queries. In bus service operations smartcard application tends to be prepaid on a yearly, monthly or weekly basis with no top-up facility for cards. Short-term passes are paper cards with embedded Smartcard technology that are disposable. This limitation is due to the quantity of stops and widespread nature of the stop network, as well as the quantity of vehicles being operated. To fit out all stops or busses with top up facilities could represent a large cost and maintenance burden that may not be cost effective. In addition, on-vehicle top-up facilities could slow passenger throughput.

Station validator units, excluding turnstile units, have the same functionality as mobile units but also provide top-up functions (cash or bankcard) and can display a wider range of passenger information. The display is usually colour touch-screen LCD type. An embedded wireless LAN device allows for data transfer and software updates or alternatively this can be done via Ethernet connection. Typically these units are top-up and passenger facilities with card validation taking place at turnstiles, however they can also include a validation capability.

Applications

  • Fare collection
  • Traveller information
  • Operations management

Benefits and cautions

Smartcard systems allow operators to minimise costs while improving customer service. A key consideration in choosing the type of system to be implemented is the scale of network and transport mode. In the case of Smartcard systems for buses, a number of practical difficulties arise in implementation. The scale of the network, the nature of stopping points and investment available all have a bearing on whether top-up functionality can be provided. For simplicity in closed-loop smartcard systems it may be better to avoid top-up services and to just issue long-terms pre-paid smartcards. Open-loop systems would be better suited to top-up functions for bus service application as cards could be topped up at ATM machines or online (for pay as you go type systems). Alternatively a partial open-loop system could be implemented through agreements made with retailers to allow top-up services in stores. This though would require large scale roll-out of reader units, and it might be simpler and more beneficial to adopt a full open-loop system instead.

Relevant case studies (please refer to Fare Collection Toolkit)

Dublin

(other relevant examples: London, Hong Kong)