The Creation Of The Oyster E System Information Technology Essay

The Creation Of The Oyster E System Information Technology Essay Introduction TfL is the body responsible for the majority of Londons transport systems. It manages London Buses, the Underground, the Docklands Light Rail (DLR) and Croydon Tramlink, Londons road network and traffic lights, traffic management and the congestion charging scheme. It runs London River Services and regulates taxis and the private hire trade. However, National rail services are not TfLs direct responsibility except some services in London (Mezghani, 2008). This paper aims to analyse TfLs Oyster ticketing system and provide a balanced assessment of its deployment, functionality and efficiency. Further, it would aim to propose recommendations pertaining to improving operability or scalability as the case may be. Oyster e-Ticketing System TfL was created in 2000 and is the integrated body responsible Londons transport system (TfL, 2010). Oyster was launched in 2003 with more than seven million Oyster cards operating in London since. Each week, fifty-seven million journeys are made using Oyster and more than 80 per cent of all bus and tube payments are now by Oyster card. TfL processes 10 million Oyster transactions a day whilst Barclaycard MasterCard processes 40 million transactions a day- half of the worlds credit card transactions (oyster-factsheet, 2010). This further elucidates the volume and importance of the Oysters operations. The Oyster card is a contactless transport smartcard which can store period tickets as well as Pre-Pay value which can be used to pay for individual fares. It encourages public transport use by reducing barriers to access, improving bus journey times and free staff from the ticket office as well as providing an integrated ticketing platform (Inglesant and Sasse, 2005). The aim of the Oyster (as of any other e-Ticketing system) is to have an open payment scheme which promotes inter-modality, inter-operability, inter-services (e-purse), parking and road pricing, customer relationship management (CRM), network monitoring and planning, secured access and individual safety (Mezghani, 2008). TfL Fare system There are a variety of tickets for both single rides and for periods of time over various modes of transportation. A capping system guarantees that an Oyster card user will be charged no more than the cheapest combinations of single tickets, travelcards and/or bus pass that cover all journeys made that day. The cap is based on modal choice, maximum zonal journey made on the Tube and time of day. A 50p discount is given where the price is capped at the travelcard or bus pass rate. Unlike paper daily travelcards, Oyster cards capped at travelcard rates are not valid on National Rail services other than those routes which accept Oyster Pay as you go. Concessionary fares exist for children, students, elderly and physically impaired people, as well as adults on some types of benefits (Mezghani, 2008). E-ticketing When discussing e-Ticketing systems, there are a few things which should be considered mandatory. These are: The fare levels and structure The ticketing spectrum The possibilities for integration The smartcard technology The interoperability issue The business case The business model The clearing mechanisms The exploitation of data However, due to the limitations of the scope of this paper only some factors will be discussed with relevance to the oyster ticketing system. Technology The Oyster card is a contactless smartcard, with a claimed proximity range of about 8  cm (3  inches). The card operates as a RFID  system and is compatible with ISO 14443A standards; although the Oyster readers can also read other types of cards including ISO14443B and Cubic Go-Cards. From its inception until January 2010, Oyster cards were based on NXP/Philips PhilipsKoninklijke Philips Electronics N.V. , most commonly known as Philips, is a multinational Dutch electronics corporation. MiFare MIFAREMIFARE is the NXP Semiconductors -owned trademark of the reputedly most widely installed contactless smart card, or proximity card, technology in the world with over 1 billion smart card chips and 10 million reader modules sold standard 1k chips provided by Giesecke Devrient Giesecke DevrientGiesecke Devrient is a German company headquartered in Munich that provides banknote and securities printing, smart cards, and cash handling systems. , Gemalto and SchlumbergerSema. Since December 2009 all new Oyster cards were produced using the MiFare DESFire  chips. From February 2010 MiFare based Oyster cards were no longer issued to the public. DESFire cards are now widely used in transport smartcard systems (Absolute Astronomy, 2010). MiFare and DESFire chips, on which the Oyster card is based, are memory smartcards, meaning that they do not have any computing power of their own. They are activated only when they are in an electromagnetic field compatible with ISO14443A. The Oyster readers provide this electromagnetic field. The readers read information from the cards, carry out computation to check whether to allow travel and to assess the payable fare and write back information to the card. Some basic information about the MiFare or DESFire chip can be read by any ISO14443A compatible reader but further, Oyster specific information cannot be read without access to the encryption used for the Oyster system. While it has been suggested that a good reader could read personal details from quite a distance there has been no evidence of anyone being able to decrypt Oyster information. By design the cards do not carry any personal information, such as names, addresses, etc. (Mezghani, 2008). As a smartcard system, the Oyster card uses a distributed settlement framework. All transactions are settled between the card and reader alone. Readers transmit the transactions to the back office in batches but there is no need for this to be done in real time. The Oyster back office system acts mainly as a record of transactions that have been completed between cards and readers. This provides a high degree of resilience in the system (Absolute Astronomy, 2010). Memory The size of the dynamic memory on a smart card into which data can be written or changed is limited, at present, both by the cost of this kind of memory (EEPROM Electrically Erasable Programmable Read Only Memory) and by the physical size of the memory chip within the cards processor. Many of the first generation read-write cards offer only a few hundred bytes of EEPROM. However, commercial cards with 4, 8 and reliably up to 64K bytes are now available- albeit at a cost. Cards with 100K bytes are also emerging. 2-4K bytes of memory is sufficient to store the financial balance and contract information, plus an auditable register of around 100 of the most recent transactions (containing information such as time, location, service, charge and final balance). However, the memory is really a function of what and how many applications the card is expected to support and this largely determines the unit cost of the card (Mezghani, 2008). Security The security of public transport systems against fraud relies on many components- which the smartcard is just one. Typically, to minimize costs, system integrators will chose a relatively cheap card and concentrate the security efforts in the back office (which also is the case with Oyster). Additional encryption on the card, transaction counters, and other methods recognized in cryptography are then required to make cloned cards useless, or at least to enable the back office detect fraud in case a card is compromised, and put it on a blacklist. Systems that work with online readers only (i.e., readers with a permanent link to the back office) are easier to protect than systems that have offline readers as well, for which real-time checks are not possible and blacklists cannot be updated as frequently (Mezghani, 2008). Mezghani (2008) recalls a presentation by Henryk Plà ¶tz and Karsten Nohl at the 24th Chaos Communication Congress in December 2007 which described a partial reverse-engineering of the algorithm used in the MiFare Classic chip, and potentially revealed some insecurities in the MiFare Classic security model, which resulted in people gaining access to transport facilities without charge. Integration In the context of fare collection, it is important to distinguish between tariff integration and ticket integration. It is important to note that integrated (multi-mode, multi-operator) fare schemes are initiatives taken or at least endorsed by transport authorities to make travel by public transport easy. Fare integration is treated differently on single tickets compared to season tickets. Single tickets tend to be mode-exclusive (e.g. surface transport vs. heavy rail) while season tickets are in most cases multi-modal. Besides, the more fare-setting is controlled by the authority, the higher fare integration becomes. E-ticketing makes ticketing integration easier to implement because it can manage a more complex fare system without necessarily harmonising amongst fares of different operators or modes. Each operator or mode keeps its own single fares and the smartcard acts as a unique means of payment. In addition, the system can include rules for transfer rights in order to be more attractive. Fares integration is no longer a pre-requisite to achieving seamless travel- this is the case with TfLs Oyster, Hong Kongs Octopus and Seouls T-Money (Mezghani, 2008). Mari (2008) in an article for computing.co.uk posed the question: Will poor integration derail smart tickets? With London 2012 in sight, its quite clear it would be very difficult for visitors to move about the country without a properly integrated ticketing system. Yes, the Oyster is focused on London and transportation for London. However, it is an opportunity to generate extra income via commissions and TfLs position is important as it is a leader in the smart e-Ticketing field. Interoperability The term interoperability can create confusion, since it can be defined in more than one way. Standardisation is an important concern in particular when it deals with interoperability. In this respect, several initiatives have been developed at national level in order to define interoperable standard specifications, e.g. ITSO standard in the UK and VDV Kernapplikations in Germany. They have jointly developed some basic concepts for European e-ticketing. A suite of three standards which serve as a generic framework has been published: a standard for data elements (EN 1545), a standard for a framework for interoperable ticketing (EN 15320, also known as IOPTA Interoperable Public Transport Application), and a basic standard for the functional interoperable fare management system architecture (ISO 24014-1, also known as IFM SA) which was additionally jointly developed with US and Japanese experts. According to IFM system architecture, there are four different levels of the interoperabil ity concept (Mezghani, 2008). This is believed to be a new gestalt in the field of smartcard e-Ticketing and will eventually become the modus operandi for all e-Ticketing technologies. Below is an illustration of the interoperable architecture applied to the Helsinki e-Ticketing system. Source: www.emta.com/IMG/pdf/EMTA-Ticketing.pdf Standardization ITSO started in 1998 and was incorporated in 2001. Its a company whose membership covers the width of the Transport arena; including transport operators (both bus and train operating companies), suppliers to the industry, local authorities and public transport executives. Supported by the Department for Transport, ITSO links with major transport industry organizations and established smartcard schemes in the UK and overseas. Having evolved from the initiative of various UK Passenger Transport Authorities who were concerned with  the lack of standards for interoperable smartcard ticketing,  ITSOs objective is to maintain and develop the ITSO Specification; to  operate and manage an interoperable smart media environment and  to facilitate and support development of interoperable smart ticketing schemes that comply with the ITSO Specification (ITSO, 2010). TfL has been working with the ITSO since 2006 and is currently expanding its interoperability through various products provided by the organization. ITSO supports the following Product Types: à ¢Ã¢â€š ¬Ã‚ ¢TYP0: Private Application à ¢Ã¢â€š ¬Ã‚ ¢TYP2: Stored Value à ¢Ã¢â€š ¬Ã‚ ¢TYP3, 17: Loyalty à ¢Ã¢â€š ¬Ã‚ ¢TYP4, 5: Charge to Account à ¢Ã¢â€š ¬Ã‚ ¢TYP14, 16: Entitlement and ID à ¢Ã¢â€š ¬Ã‚ ¢TYP22, 23, 24: Pre-defined Tickets à ¢Ã¢â€š ¬Ã‚ ¢TYP25: Voucher à ¢Ã¢â€š ¬Ã‚ ¢TYP26: Tolling à ¢Ã¢â€š ¬Ã‚ ¢TYP27, 28, 29: Space-saving Tickets à ¢Ã¢â€š ¬Ã‚ ¢TYP34: Transient Ticket The diagrams below illustrate the structure of the ITSO system and its benefits. ITSO System Overview. Source:www.ctst.com/CTST08/pdf/Hochfield.pdf ITSO stored value proposition Source: http://www.itso.org.uk/page45/About%20ITSO/ Weinstein (2009) elucidates the options Oyster has in expanding its scope and maintaining efficiency by stating the need to look outward; especially at other e-Ticketing systems around the world and learn from advancement in these systems or the transport schemes put in place. The EMV standard could be a path to inter-operability as it uses global networks that already exist and that work effectively every day for millions of purchases (Weinstein, 2009). Conclusion There are several reasons transport authorities introduce or re-model e-Ticketing systems. However, they do not have the same priorities. With EMV gradually gaining ground, Oyster is constantly striving to ease customer experience as well as strengthen its competitive advantage. However, the main focal point for the Oyster should be scalability. This ensures seamless integration when new technology is introduced and platform independence as a result of interoperability. It also aids data mining which serves as input for future modelling and design. Scalability should, above anything, be the primary focus of Oyster as it forecasts.