an efficient auction based tatkal scheme for indian railway
DESCRIPTION
Auction TatkalTRANSCRIPT
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, Air-
Conditioned 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-come-
first-serve basis when passenger’s 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-first-
serve 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
Online Reservation System (TATKAL scheme)
Passenger logins
Passengers submit their bids
Passengers can view other’s bids and update their own
Admin registers new passengers
Admin starts the auction for a given time slot
Admin allocates the ticket to the highest
bidder
Admin sends the confirmation SMS
New passenger registers
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 PC’s 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 database’s 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 organization’s 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 PURPOSESOURCE OF INPUT /
DESCRIPTION OF OUTPUT
Keyboard To send auction bids from
registered passengers
Source of input, Client
TATKAL scheme To allocate tickets for highest
bidder
Administrator
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 user’s 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 1
Critical 2
Marginal 3
Negligible 4
No. Risk Category Probability Impact
1 Increase of work load Personal 20% 3
2 Inexperience in Project
software environment
Technical 25% 3
3 Overly optimistic schedules Project 20% 3
4 Lack of sufficient research Technical 50% 3
5 Modules require more
testing and further
implementation work
Project 50% 2
6 Inconsistency in Input Project 30% 3
Milestones and Timelines
Number Milestone
Name
Milestone Description Timeline
Week no.
from the start
Remarks
of the project
1 Requirements
Specification
Complete
specification of the
system (with
appropriate
assumptions) A
document detailing
the same should be
written and a
presentation on that
be made.
2-3 Attempt should be
made to add some
more relevant
functionality other than
those that are listed in
this document.
2 Technology
familiarization
Understanding of the
technology needed to
implement the entire
project.
4-5 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
some entries of
detailed information
regarding all basic
requirement.
5-7 It is important to finalize
on the database at this
stage itself so that
development and
testing can proceed
with the actual
database itself.
4 High-level and
Detailed Design
Listing down all
possible scenarios
(like application
approval , rejection,
cancellation,
automatic
7-9 The scenarios should
map to the requirement
specification (ie, for
each requirement that
is specified, a
corresponding scenario
redemption etc) and
then coming up with
flow-charts or pseudo
code to handle the
scenario.
should be there).
5 Implementation
of the front-end
of the system
Implementation of
the main screen
giving the created
project specific
domain name and the
host for 24hr
availability of the
system, screen that
follows the welcome
page giving various
options, screens for
each of the options
10-12 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 test-
plan can be updated as
and when new
scenarios come to mind.
6 Integrating the
front-end with
the database
The front-end
developed 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
12-13
testing.
7 Integration
Testing
The system should be
thoroughly tested by
running all the test
cases written for the
system (from
milestone 5).
14-15 Another 2 weeks should
be there to handle any
issues found during
testing of the system.
After that, the final
demo can be arranged.
8 Final Review Issues found during
the previous
milestone are fixed
and the system is
ready for the final
review.
16-18 During the final review
of the project, it should
be checked that all the
requirements specified
during milestone
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