An efficient auction based TATKAL scheme for Indian Railway

Abstract
Indian Railways have one of the biggest infrastructures in terms of number of Express trains run per day across cities. It is comparable to any railways in the world. For each Express train there is a TATKAL scheme that reserves few seats on emergency basis. In the existing scheme for each seat a ticket is issued after charging a fixed price. However, for different distance different fixed price is charged. The allocations of tickets are purely based on the first-come-first-serve basis. But from our experience we have seen that the urgency of a person standing in the queue may be much more than any other person in front of him and that person is ready to pay a higher price than the fixed one to get the ticket, in case the tickets are exhausted before his turn coming. So, since the Indian railways charge a fixed price, they lose a significantly large amount of revenue as a considerable number of travellers may be willing to pay a much higher price than the fixed price for an assured reservation. In this paper we have proposed an auction based truthful mechanism for selling some tickets of TATKAL scheme and have shown that our auction based scheme is significantly better than the existing scheme in terms of the total income earned per annum. Our scheme could be applied in any railway system.

Introduction
To meet the urgent requirement of the passengers who plan their journey at short notice, Tatkal reservation facility has been provided in Sleeper Class, Air-conditioned Chair Class, and 3-AC & 2-AC classes in almost all Mail/Express trains including special trains. The advance reservation period under this scheme is one day excluding the day of journey. Proof of identity is required to be produced by the passenger seeking reservation under Tatkal Scheme, at the time of booking as well as during the journey. The new tatkal charges will be at the rate of 10 per cent of basic fare for second class and 30 per cent of basic fare for all other classes subject to minimum and maximum charges for each class. The minimum charge for second class (sitting) is 10 rupees and the maximum will be 15 rupees, for sleeper class and AC chair car the minimum has been fixed at 75 rupees and the maximum at 150 rupees, while for AC III and AC II tier classes the minimum will be 200 rupees with the

maximum being 300 rupees. Tatkal tickets will be issued for actual distance of travel, instead of end-to-end, subject to the distance restriction applicable to the train. The same tatkal berth/seat may be booked in multiple legs till preparation of charts. At the time of preparation of charts, unutilized portion may be released to the General RAC/Waiting list passengers. Tatkal Booking starts one day in advance excluding the day of journey e.g. for a journey on 3rd, bookings would open at 10 am on 2nd. However, the day of journey is defined as the day of chart preparation. So if the train starts e.g. on 3rd, and reaches the desired boarding station on 4th, the Tatkal booking will start on 2nd and not 3rd. Copy of identity is required to be produced at the time of booking the ticket. However as of February 11th 2011, the passenger will be required to furnish ID such as a PAN Card, Passport, Driver's Licence, etc. during the actual journey. There will be no separate Tatkal train defined. Non-utilised Tatkal tickets are released to wait-listed passengers. Tickets in this scheme can be cancelled but no refund is made. In those trains and in those classes where average utilization of Tatkal accommodation during peak period i.e. April to September is 80% and above, Tatkal charges applicable during peak period will be charged throughout the year i.e. for both peak and non-peak periods. The Advance Reservation period (ARP) of Tatkal scheme has been reduced from 2 days at present to 1 day excluding the day of journey from the train originating station. Tatkal ticket will be issued on production of one of the eight prescribed proofs of identity. For this purpose, a self attested photo copy of the identity card on which the passenger proposes to travel shall be attached to the requisition slip. The details of the identity proof shall be captured by the system and indicated on the reserved tickets as well on the chart. It will not be mandatory for the passengers to go to the counter to book the Tatkal ticket; however, the proof will have to be sent in the aforementioned manner. During the journey, the passenger will have to produce original proof of identity indicated on the ticket. In future, when AADHAAR is operational, the issue of Tatkal tickets will be linked to AADHAAR.

Literature Survey
Indian Railways have a very big infrastructure (throughout) India. There are so many categories of trains. Mainly there are three kinds of trains:

 Local trains which run a short distance. Passenger trains which run a medium distance. Express trains which run usually a long distance. In each Express train there are three broad classes. One is called general class which does not require any reservation. There are few compartments which are Air-Conditioned. Very few trains are there which are fully air-conditioned. Based on the amenities provided, AirConditioned compartments are categorized in different classes. Rest of the Compartments which does not have Air-Condition are categorized as Sleeper Class. The Sleeper Class consisting of many compartments for most of the express trains. If anybody wants to travel by an Express train he or she has to reserve a ticket except for the general class. The general situation is like this. If a train is having 15 compartments then 3 of them could be of general category, 10 of them are of Sleeper class, 2 of them are of AC class. This may vary slightly from train to train. As many compartments are of Sleeper class we will discuss our scheme considering this class. This scheme could be utilized in other classes also. The present reservation scheme is as follows: Say there are 10 compartments for the Sleeper class and in each compartment 80 seats are available altogether. So there are 800 seats to be reserved for each train. The current scenario is such that there is heavy trafficking for booking of train tickets each day. Usually no seat is left vacant and our discussion will be based on that assumption. At present the situation is such that out of 800 seats almost 70% seats are made public for reservation on a day at least two months prior to the travel date. Rest of the 30% seats are made available 3 days prior to the scheduled departure time on an urgent basis and a fixed price with some extra cost is charged for each ticket and that price also is fixed for the same distance. The tickets are sold on a first-comefirst-serve basis when passengers line-up in the reservation counters or book through Internet. This scheme is called TATKAL scheme that is the scheme of urgency. But from our experience we have seen that there is a huge demand for the tickets that are reserved through this scheme. And people in urgent need of a ticket are ready to pay extra amount to get it.

Problem Statement

The tatkal tickets are sold on a of first-cum-first-service basis. But from our experience we have seen that there is a huge demand for the tickets that are reserved through this scheme. And people in urgent need of a ticket are ready to pay extra amount to get it. So our statement is to point out that if people are ready to pay extra amount of money for a ticket than the fixed rate, is the present scheme a good scheme when we look in terms of benefit we earn? Obviously the answer is no as the price is fixed and we are not considering the urgency of the people for purchasing the same ticket with a much higher price.

Existing System
In the case of TATKAL scheme for reserving the seats for a train a passenger goes to a computerized reservation centres and stands in a queue or can book a ticket through Internet via e-ticket. There are k seats available and there are n passengers trying to get the k tickets (where k < n). In the present scheme the tickets are sold in the first-come-firstserve manner and each buyer of the ticket is charged a fixed amount of money. However for different distance different fixed price is charged. In the present TATKAL scheme k tickets, where k k, are reserved for the source station. We see that there is no guarantee that the entire seat will be booked for the duration of the journey. If a seat is not booked for the whole distance of the journey from source to destination, the rail company will suffer large amount of losses for each seat being occupied in this way.

Proposed System
We propose an auction based tatkal scheme for passengers to book tickets for the train journey. We mainly focus on the passengers travelling from the source to the destination station. In this system, the registered passengers will submit their bids for the tickets accordingly in the given time slot. Passengers can view the bids coming from other passengers and update their bids accordingly. The administrator will sort the bids according to the bid price and ticket will be allocated to the highest bidder accordingly. A confirmation SMS will be sent to the user winning the auction.

Project Scope

Experience says that a person who is not getting a ticket may have a very high demand for a ticket and is ready to pay a higher price than the fixed price which is charged for each ticket. So it will be both rational and profitable to sell a ticket to a person with a greater demand for it and offering a higher price for it rather than to sell it merely on first-come-first-serve basis. In this situation auction is, we believe, the best scheme to be adopted.

System Design

Passenger logins

Admin registers new passengers

New passenger registers Online Reservation System (TATKAL scheme) Passengers submit their bids

Admin starts the auction for a given time slot

Admin allocates the ticket to the highest bidder

Passengers can view others bids and update their own

Admin sends the confirmation SMS

System Requirements
Software Requirements: Operating system: Windows XP Technology Used: ASP.net IDE: Microsoft Visual Studio 2008 Database: MS Access/Microsoft SQL Server 2005

Hardware Requirements Processor: Pentium P4 Motherboard: Genuine Intel RAM: Min 1 GB Hard Disk: 80 GB

Requirement Analysis
To demonstrate the working of this software there should exist an environment with a proper online setup with all the adequate access rights granted to the individual PCs so that they could be remotely monitored. Feasibility Analysis Preliminary investigation examine project feasibility, the likelihood the system will be useful to the organisation. The main objective of the feasibility study is to test the Technical, Operational and Economical feasibility for adding new modules and debugging old running system. All system is feasible if they are unlimited recourses and infinite time. There are aspects in the feasibility study portion of the preliminary investigation: Technical Feasibility Operational Feasibility Economical Feasibility TECHNICAL FEASIBILITY The technical issue usually raised during the feasibility stage of the investigation includes the following: Does the necessary technology exist to do what is suggested?

 Do the proposed equipments have the technical capacity to hold the data required to use the new system? Will the proposed system provide adequate response to inquiries, regardless of the number or location of users? Can the system be upgraded if developed? Are there technical guarantees of accuracy, reliability, ease of access and data security? The current system developed is technically feasible. It is a many-to-one user interface for online auction. Thus it provides an easy access to the Administrator. The databases purpose is to mainly facilitate communication between the passenger and the administrator. As the Server Application is exclusively run only on the Server PC, it provides Security and no chances of misuse. The software and hard requirements for the development of this project are not many and are already available in any organizations. The project is deployed in a local server provided by Microsoft. Hence it is not needed to explicitly set up a server only for the deployment of this project. The work for the project is done with the current equipment and existing software technology. Necessary bandwidth exists for providing a fast feedback to the users irrespective of the number of users using the system. OPERATIONAL FEASIBILITY Proposed projects are beneficial only if they can be turned out into information system. They will meet the organizations operating requirements. Operational feasibility aspects of the project are to be taken as an important part of the project implementation. Some of the important issues raised are to test the operational feasibility of a project includes the following: Is there sufficient support for the management from the users? Will the system be used and work properly if it is being developed and implemented? Will there be any resistance from the user that will undermine the possible application benefits?

This system is targeted to be in accordance with the above-mentioned issues. Beforehand, the management issues and user requirements have been taken into consideration. So there is no question of resistance from the users that can undermine the possible application benefits. The well-planned design would ensure the optimal utilization of the computer resources and would help in the improvement of performance status. ECONOMICAL FEASIBILITY A system can be developed technically and that will be used if installed must still be a good investment for the organization. In the economical feasibility, the development cost in creating the system is evaluated against the ultimate benefit derived from the new systems. Financial benefits must equal or exceed the costs. The system is economically feasible. It does not require any additional hardware or software. The local server is already available in the Organization. Since the interface for this system is developed using the existing resources and technologies available at any organization. There is nominal expenditure and economical feasibility for certain. Also as the System is designed with a purpose to curtail the costs of Electricity, it adds up to the Economic value of the Project. SYSTEM ANALYSIS After analyzing the requirements of the task to be performed, the next step is to analyze the problem and understand its context. The first activity in the phase is studying the existing system and other is to understand the requirements and domain of the new system. Both the activities are equally important, but the first activity serves as a basis of giving the functional specifications and then successful design of the proposed system. Understanding the properties and requirements of a new system is more difficult and requires creative thinking and understanding of the existing running system is also difficult, improper understanding of present system can lead diversion from solution.

Analysis Model

The model that is basically being followed is the WATERFALL MODEL, which states that the phases are organised in a linear order.

Waterfall Model WATERFALL MODEL: Waterfall approach was first Process Model to be introduced and followed widely in Software Engineering to ensure success of the project. In "The Waterfall" approach, the whole process of software development is divided into separate process phases. The phases in Waterfall model are: Requirement Specifications phase, Software Design, Implementation and Testing & Maintenance. All these phases are cascaded to each other so that second phase is started as and when defined set of goals are achieved for first phase and it is signed off, so the name "Waterfall Model". All the methods and processes undertaken in Waterfall Model are more visible. The stages of "The Waterfall Model" are:

Requirement Analysis & Definition: All possible requirements of the system to be developed are captured in this phase. Requirements are set of functionalities and constraints that the end-user (who will be using the system) expects from the system. The requirements are gathered from the end-user by consultation, these requirements are analyzed for their validity and the possibility of incorporating the requirements in the system to be development is also studied. Finally, a Requirement Specification document is created which serves the purpose of guideline for the next phase of the model. System & Software Design: Before a starting for actual coding, it is highly important to understand what we are going to create and what it should look like? The requirement specifications from first phase are studied in this phase and system design is prepared. System Design helps in specifying hardware and system requirements and also helps in defining overall system architecture. The system design specifications serve as input for the next phase of the model. Implementation & Unit Testing: On receiving system design documents, the work is divided in modules/units and actual coding is started. The system is first developed in small programs called units, which are integrated in the next phase. Each unit is developed and tested for its functionality; this is referred to as Unit Testing. Unit testing mainly verifies if the modules/units meet their specifications. Integration & System Testing: As specified above, the system is first divided in units which are developed and tested for their functionalities. These units are integrated into a complete system during Integration phase and tested to check if all modules/units coordinate between each other and the system as a whole behaves as per the specifications. After successfully testing the software, it is delivered to the customer. Operations & Maintenance: This phase of "The Waterfall Model" is virtually never ending phase (Very long). Generally, problems with the system developed (which are not found during the development life cycle) come up after its practical use starts, so the issues related to the system are solved after deployment of the system. Not all the problems come in picture directly but they arise time to time and needs to be solved; hence this process is referred as Maintenance.

Advantages of Waterfall Model Waterfall model is the oldest and most widely used model in the field of software development. There are certain advantages of the waterfall model, which causes it to be the most widely used model as yet. Some of them can be listed as under. Needless to mention, it is a linear model and of course, linear models are the most simple to be implemented. The amount of resources required to implement this model is very minimal. One great advantage of the waterfall model is that documentation is produced at every stage of the waterfall model development. This makes the understanding of the product designing procedure simpler. After every major stage of software coding, testing is done to check the correct running of the code. Disadvantages of Waterfall Model The question that must be bothering you now is that with so many advantages at hand, what could be the possible disadvantages of the waterfall model. Well, there are some disadvantages of this widely accepted model too. Let us look at a few of them. Ironically, the biggest disadvantage of the waterfall model is one of its greatest advantages. You cannot go back, if the design phase has gone wrong, things can get very complicated in the implementation phase. Many a times, it happens that the client is not very clear of what he exactly wants from the software. Any changes that he mentions in between may cause a lot of confusion. Small changes or errors that arise in the completed software may cause a lot of problem. The greatest disadvantage of the waterfall model is that until the final stage of the development cycle is complete, a working model of the software does not lie in the hands of the client. Thus, he is hardly in a position to mention if what has been designed is exactly what he had asked for.

Functional Requirements

User Interfaces: The interface used in GUI must be easy to understand. This interface serves as a bridge between the user and the software. It also makes the user interaction with the system easy. The user interface includes: Screen formats / Organizations: The introductory screen will be the first to be displayed which allows the user to log in using their id and password. Windows formats / Organizations: When the user chooses a particular topic then the information pertaining to that topic will be displayed in a new window, which will allow multiple windows to be available on the screen, and the user can switch between them. Data Format: The data entered by the user will be alphanumeric. End Message: When there are some exceptions, error messages will be displayed promptly by the user to re-enter the details when an event has taken place successfully. Hardware interfaces: The system must basically support certain hardware and these must be an interface between them.

NAME OF THE ITEM

DESCRIPTION OF PURPOSE

SOURCE OF INPUT / DESCRIPTION OF OUTPUT

Keyboard

To send auction bids from Source of input, Client registered passengers

TATKAL scheme

To allocate tickets for highest Administrator bidder

Communication interfaces The administrator keeps all the details of the registered passengers in the database. The communication is established with the help of an online system where the passenger submits their bids for tickets and the administrator allocates the ticket to the highest bidder. A confirmation SMS is sent to the winner of the auction.

Non-functional Requirements
Performance requirement: Some Performance requirements identified is listed below:

 The database shall be able to accommodate a minimum of 10,000 records of customers. The software shall support use of multiple users at a time for chat system. There are no other specific performance requirements that will affect development Safety requirement: The database may get crashed at any certain time due to virus or operating system failure. Therefore, it is required to take the database backup. Security requirement: Application will allow only valid users to access the system. Access to any application resource will depend upon users designation. There are three types of users namely Administrator, Clients and Customers. Security is based upon the individual user ID and Password. Some of the factors that are identified to protect the software from accidental or malicious access, use, modification, destruction, or disclosure are described below. Keep specific log or history data sets Check data integrity for critical variables Assign certain functions to different modules Restrict communications between some areas of the program Check data integrity for critical variables Communication needs to be restricted when the application is validating the user or license.

Risk Analysis
RMMM plan tackles risk through Risk Assessment and Risk Control. Risk Assessment involves Risk Identification, Risk Analysis and Risk Prioritization. While Risk Control involves Risk Management Planning, Risk Resolution and Risk Monitoring. Purpose: The RMMM plan outlines the risk management strategy adopted. We adopt a proactive approach to tackle risks and thus reduce the performance schedule and cost overruns, which we may incur due to occurrence of unexpected problems. This Risk Mitigation Monitoring and Management Plan identifies the risks associated with our project. In addition to project risk and technical risks, business risks are also identified, analyzed and documented. This document outlines the strategy that we have adopted to avoid these risks. A

contingency plan is also prepared for each risk, in case it becomes a reality. Only those risks have been treated whose probability and impact are relatively high i.e. above a referent level. Risk Table Impact levels: The risks are categorized on the basis of their probability of occurrence and the impact that they would have, if they do occur. Their impact is rated as follows: Catastrophic Critical Marginal Negligible No. 1 2 Risk Increase of work load Inexperience in 1 2 3 4 Category Personal Probability 20% 25% Impact 3 3

Project Technical

software environment 3 4 5 Overly optimistic schedules Project Lack of sufficient research Modules testing require and Technical 20% 50% 50% 3 3 2

more Project further

implementation work 6 Inconsistency in Input Project 30% 3

Milestones and Timelines

Number

Milestone Name

Milestone Description

Timeline

Remarks

Week no. from the start of the project 1 Requirements Specification Complete specification of the system appropriate assumptions) document A detailing (with 2-3 Attempt made more to should add be some

relevant

functionality other than those that are listed in this document.

the same should be written and a

presentation on that be made. 2 Technology familiarization Understanding of the 4-5 technology needed to implement the entire project. The presentation should be from the point of view of being able to apply it to the project, rather than from a

theoretical perspective. 3 Database creation A database of at least 5-7 some entries of It is important to finalize on the database at this stage itself so that and proceed actual

detailed information regarding all basic

development testing with can the

requirement.

database itself.

High-level

and Listing

down

all 7-9

The scenarios should map to the requirement specification (ie, for

Detailed Design possible (like

scenarios application

approval , rejection, cancellation, automatic redemption etc) and then coming up with flow-charts or pseudo code to handle the scenario. 5 Implementation Implementation main the of 10-12

each requirement that is specified, a

corresponding scenario should be there).

During this milestone period, it would be a good idea for the team (or one person from the team) to start working on a test-plan for the entire system. This testplan can be updated as and when new

of the front-end the of the system giving

screen created specific

project

domain name and the host for of 24hr the

availability

system, screen that follows the welcome page giving various

scenarios come to mind.

options, screens for each of the options 6 Integrating the The front-end with developed the database front-end 12-13 in the

earlier milestone will now be able to

update the system Other features like geographic

coordinate notification etc

should be functional at this stage. In short, the system should be ready for integration testing. 7 Integration Testing The system should be 14-15 thoroughly tested by running all the test cases written for the system milestone 5). 8 Final Review Issues found during 16-18 the previous (from Another 2 weeks should be there to handle any issues found during

testing of the system. After that, the final demo can be arranged. During the final review of the project, it should be checked that all the requirements specified during milestone

milestone are fixed and the system is ready for the final review.

number 1 are fulfilled (or appropriate reasons given for not fulfilling the same)

Conclusion & Future Scope

Our auction based TATKAL scheme for the Indian railway could be applied in any railway system and a huge profit could be earned. In our scheme we are closing the auction before four hours of the schedule departure of a train. But a person who comes to the source station for catching the train may have to travel a long distance before reaching there. But if we close the auction before four hours of the schedule departure of the train, and if the

information of the allocation of the tickets is sent via Mobile service or is displayed via Internet, four hours may not be sufficient. In our future works we are working on it to make the system more convenient for the travellers so that the passengers could have a choice to wait for a certain time and after that they could stop bidding.

References
[1] N. Nisan and A. Ronen, Algorithmic Mechanism Design.Games Econ.Behav., .35:166-196, 2001. [2] Noam Nishan and Tim Roughgarden et al.Algorithmic Game Theory Cambridge University Press, 2007. [3] T. Groves.Incentives in teams. Econometrica, 617-631, 1973. [4] P. Klemperer. Auctions: Theory and Practice.Princeton University Press, 2004. [5] Y. Bartal, R. Gonen, and N. Nisan. Incentive compatible multiunit combinatorial auction. In 9th Conf. Theor. Aspects of Rationality and Knowledge,pp. 72-87,2003. [6] P. Cramton, Y. Shoham, and R. Steinberg(Editors).Combinatorial Auctions MIT Press, 2006. [7] L.M.Ausubel. An efficient dynamic auction for heterogeneous commodities. Amer. Econ. Rev. 96(3):602-629, 2006. [8] P.Briest,P. Krysta, and B. Vocking. Approximation techniques for utilitarian mechanism design.In the 37th ACM Symp. Theor. Comp., pp. 39-48, 2005. [9] http://en.wikipedia.org/wiki/Indian Railways. [10] http://www.irfca.org/faq/faq-travel.html [11] http://www.indiarail.co.uk/indrail.htm