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