An Optimization-Based Decision Support System for Train Scheduling

Ravindra K. Ahuja, Mohammad Jaradat, Krishna C. Jha, and Arvind Kumar 2153 SE Hawthorne Road, Suite 128, Gainesville, FL 32641, USA www.InnovativeScheduling.com Pooja Dewan Technology Services BNSF Railway, 2400 Lou Menk Drive Fort Worth, TX 76131, USA

(Revised August 1, 2006)

TABLE OF CONTENTS
EXECUTIVE SUMMARY 1. INTRODUCTION 2. THE TRAIN SCHEDULING PROBLEM OVERVIEW INPUT DATA OUTPUT DATA DECISION VARIABLES OBJECTIVE FUNCTION 3. LITERATURE REVIEW 4. A DECOMPOSITION APPROACH TO TRAIN SCHEDULING PHASE I: TRAIN ROUTE DESIGN PHASE II: TRAIN DETAILS DESIGN INTEGRATING RAILCAR, CREW, AND LOCOMOTIVE CONSIDERATIONS IN TRAIN SCHEDULING 5. INCREMENTAL TRAIN SCHEDULING 6. A DECISION SUPPORT SYSTEM FOR TRAIN SCHEDULING 7. COMPUTATIONAL RESULTS 8. A WEB-BASED TRAIN SCHEDULING DECISION SUPPORT SYSTEM 9. AN INTEGRATED SOFTWARE SUITE FOR SERVICE DESIGN ABOUT THE AUTHORS ABOUT INNOVATIVE SCHEDULING 1 2 4 4 6 7 8 8 12 13 13 14 16 17 20 23 24 27 31 33

EXECUTIVE SUMMARY
This paper describes the development of a decision support system for developing a railroads operating plan that enables efficient movement of railcars, blocks, trains, crew and locomotives in an integrated manner. Designing such an operating plan is a very large-scale and very complex multi-objective optimization problem that, to date, has defied a satisfactory solution. Determining an operating plan for a railroad consists of two steps: determining a blocking plan followed by determining a train schedule. We have already developed a decision support system to determine the blocking plan, shortly after we developed a decision support system for determining the train schedule to compliment the decision support system. In this paper, we describe our decision support system for train scheduling. An important feature of our methodology is that it considers the costs required by cars, crew, and locomotives in an integrated manner while determining the train schedule so that the sum total of these costs is minimal while honoring a variety of practical constraints (including line, yard, and train capacities) that are necessary to generate an implementable schedule. Our method runs in two modes: zero-base mode or incremental mode. In the zero-base mode, our method obtains a clean-slate train schedule to minimize system-wide costs. In the incremental mode, it incrementally changes a given train schedule (by 5%, for example) to obtain maximal cost savings. Train scheduling consists of determining how many trains to run; the origin, destination, and route of each train; the train arrival and departure times for each station at which it stops; the weekly operating schedule for each train; and the assignment of blocks of cars to trains by day of the week. The train schedule must satisfy numerous practical constraints and business rules and achieve the minimum cost of transportation. This problem is a very large-scale, multi-objective optimization problem containing trillions of decision variables. We have developed a customized, decomposition-based method using state-of-the-art network optimization and heuristic techniques so that this problem can be solved within a few hours of computer time on a workstation. These algorithms are being packaged into a web-based decision support system with attractive and friendly graphical and geographical interfaces that allow sufficient user control. A computerized method for train scheduling will enable a service design department at a railroad to frequently perform incremental changes to its train schedule to accommodate changes in traffic patterns or disruptions.

1. INTRODUCTION
This paper describes the development of a decision support system for the train schedule design problem, one of freight railroad transportations most significant optimization problems. Railroad transportation presents a rich collection of optimization problems; however, the modeling complexity of these problems has precluded the development of optimization algorithms for solving them. As a result, the railroads have not benefited from the advances taking place in the field of modeling and optimization; they still rely on manual decision-making processes for most of their planning and scheduling needs. However, this situation is gradually changing as new innovations have taken place on algorithmic and implementation fronts and computing speeds have increased dramatically. Using cutting-edge modeling and optimization techniques, we have developed a novel approach to solve the train scheduling problem and have packaged it into a decision support system. This paper describes the features and functionalities of our software. Americas railroads now carry more ton-miles of freight annually than ever before in the history of the industry. Americas highways, ports, and railroads already frequently reach capacity and several services melt down due to localized gridlocks. Railroad companies recognize that resolving this dilemma requires building new infrastructure in bottleneck areas, and squeezing more productivity out of existing track, railcars and locomotives. We are developing new, cutting-edge operations research techniques that can be applied to railroad networks to help business managers intelligently ration scarce capacity. Our tools will help strategic planners improve productivity and target the best places to invest limited capital dollars. Optimal train scheduling will unlock hidden capacity in the current network by creating more efficient train schedules, balanced terminal plans, and faster railcar routings. In this paper, we give the details of a decision support system for train scheduling, which will have a significant and positive impact on improving a railroads efficiency and its responsiveness to changes in traffic patters. Central to any freight railroads operations is the Operating Plan which dictates the movement of shipments (railcar loads), crews, and locomotives over the railroads network (see Exhibit 1). Each railroad company has a service design department responsible for creating operating plans that enable efficient movement of shipments. An operating plan consists of a blocking plan and a train schedule. The blocking plan determines how to aggregate a large number of shipments into blocks of shipments as they travel from origins to destinations. This consolidation process is similar to the process performed in a post office where all the packages originating from a city are grouped into a small number of mailbags by the destination zip code. Train scheduling consists of designing train routes, train days of operation, train timings, and routing of blocks on trains that minimize the total system-wide cost, including car hire, crew and locomotive costs. An operating plan can have a significant impact on a railroads operations as it determines the flow of three very important railroad assets: crews, locomotives, and railcars, consuming billions of dollars of operating costs for Class I railroads. An operating plan significantly impacts these costs and a well-designed operating plan can reduce them significantly.

1. INTRODUCTION

Blocking Plan Design Operating Plan Train Schedule Design

Crew Scheduling

Locomotive Scheduling

Railcar Scheduling

Exhibit 1: Operating Plan Development Process. Developing an operating plan for a large US railroad that satisfies various operating constraints and business rules and, at the same time, optimally uses the railcar, crew and locomotive resources, is a very challenging task. This requires several months of painstaking effort by a team of highly experienced service designers. It is widely known that US railroads face a large-scale retirement of seasoned and experienced personnel in the next five years. Thus, US railroads are looking for software tools that can decrease their reliance on human experience and substitute it by computerized logic to the maximum extent possible. They are looking for a decision support system that will enable their less experienced service design professionals to develop implementable operating plans quickly. Innovative Scheduling is developing decision support systems to meet this need. We have already developed a decision support system for the railroad blocking problem. Our train scheduling decision support system, when integrated with the railroad blocking decision support system, will offer a complete software suite to the operating plan development process. Our operating plan design software suite can be used in either the clean-slate mode or the incremental mode. In the clean-slate mode, we determine a brand-new unrestricted operating plan, and in the incremental mode, we incrementally change a given operating plan to identify improvements resulting in maximum cost savings. We expect that using this suite, the clean-slate operating plan can be developed within two-three weeks and incremental changes to the operating plan can be done within a week. We also expect that the availability of this software suite and the ability to develop new operating plans will quickly make a railroad more responsive to traffic changes and also reduce operating costs.

2. THE TRAIN SCHEDULING PROBLEM

In this section, we describe the train scheduling problem, its objective functions, and its constraints. The train scheduling problem consists of determining a weekly train schedule and assigning blocks to trains such that the total system-wide transportation cost is minimal. We assume that a train schedule is repeated every week in the planning horizon.

2.1 OVERVIEW
The train scheduling problem consists of four entities: the physical (railroad) network, trains which travel on the physical network, blocks which travel on the trains, and shipments (or cars) consolidated into blocks. We illustrate these entities using a simple example. Exhibit 2 shows a geographical network with three trains traveling on it. Train A starts at node 1, follows the route 1-6-7-8-9, and terminates at node 9. Train B follows the route 2-3-4-9, and train C traverses the path 1-2-5-9. Three blocks of shipments, b1, b2, b3, travel on these trains. (A block is a set of cars with the same origin and destination nodes.) Block b1 takes train A over the train segments 1-6-7, while block b2 takes the same train over the segments 6-7-8. Thus, as a train travels from its origin to its destination, it picks up blocks at various nodes it visits and may also drop off blocks at those nodes. Typically, several blocks ride on a train at any segment. A block may also travel on several trains as it goes from its origin to its destination. For example, block b3 starts at node 1 and travels on train C on the segment 1-2. It is offloaded by train C at node 2, where it is picked up by train B and carried from node 2 to node 4, its destination. The transfer of a block from one train to another is called a block swap. Among the blocks in our example, only block b3 performs a block swap. block b3 2 3 4

Train B

Train C

block b1

Train A

block b2

Exhibit 2: Illustrating the interplay among physical network, trains, and blocks.

2. THE TRAIN SCHEDULING PROBLEM

The preceding example provides a brief overview of the structural components of the train scheduling problem. In this problem, there are seven types of decisions to be made: What is the number of trains to run? What are the origin, destination, and route of each train? What are the arrival and departure times at each station that a train visits? What is the frequency of each train? In other words, how often should it run in a week and on what days? How should blocks be assigned to trains by the day of the week? How should cars be assigned to trains? How should locomotives and crews be assigned to trains?

Exhibit 3 gives an overview of our decision support system for train scheduling. We call the optimization engine that solves the train scheduling problem the train scheduling optimizer. The inputs to the optimizer are geographical network, shipments, blocks, and crew network inputs. The outputs of the optimizer are optimized train schedule, routings of blocks and shipments, and crew and locomotive assignments. The exhibit also lists the decision variables, objective functions, and constraints of the train scheduling problem.

Geographical nodes and links Shipments waybills and blocks Train current train plan Crew segments Locomotive data

Train Scheduling Optimizer

Input

Objective Function:

Constraints: Business Rules

Car days and car miles Train starts and train miles Block swaps Locomotive and crew costs

Geographical network Trains Blocks and shipments Locomotives and crew

Network activity at each node/link Trains routes, timings, and frequencies Shipment plan block-to-train assignment and trip plan Locomotive and crew plan

Exhibit 3: Overview of the train scheduling problem.

Output

2. THE TRAIN SCHEDULING PROBLEM

2.2 INPUT DATA

The train scheduling optimizer takes two types of input data: essential and optional. The essential data must be provided to the optimizer, whereas the optimizer may use system default values for the optional data. Exhibit 4 gives the detail of these two data inputs.

Node Node ID Yard Type Time Zone Max Num of Orig. Trains Max Num of Term. Trains Max Num of Thru Trains Max Num of Block Swaps Intermediate PU/SO Flag New Train Preference Stop Duration for PU/SO Minimum Switching Time Minimum Swapping Time Locomotive Connection Time

Link Link Tail Node ID Link Head Node ID Physical Distance Impedance Factor Train Flow Capacity Average Speed of Train Horse Power per Ton Max Num of Cars in a Train Max Length of a Train Max Weight of a Train Plate Clearance

Crew Crew ID Crew Home Node ID Crew Away Node ID Crew Rest Time at Home Node Crew Rest Time at Away Node Locomotive Pulling power (HP) of a Loco Min Num of Locos pet Train

Geographical Network, Crews, and Locomotives

Block Summary Block ID Block Origin Node ID Block Destination Node ID Max Number of BTAs Max Num of Trains in a BTA Max Path Detour

Shipment Shipment ID Origin Node ID Destination Node ID Number of Cars Total Length Total Weight Release Day of week Release Time

Shipment-Block Sequence Shipment ID Block Sequence Number Block ID

Blocks and Shipments

Train Summary Train Train Train Train ID Origin Node ID Destination ID Frequency

Train Route Train ID Stop Sequence Number Stop Node ID Train Arrival Day/Time Train Departure Day/Time Crew Change Flag

BTA Block ID BTA ID Train ID Train Seq. Number Block Pickup Node ID Block Setoff Node ID

Trip Plan Shipment ID Block ID Train ID Train Operating Day Pickup Node ID Pickup Day/Time Setoff Node ID Setoff Day/Time

Existing Solution

Text Color Legend: Green Essential Data, Red We can use system default values.

Exhibit 4:

Input Data for the Train Scheduling Optimizer.

2. THE TRAIN SCHEDULING PROBLEM

2.3 OUTPUT DATA

Train schedules affect the utilization of all the important resources of a railroad. Therefore, the output from the software must be detailed enough to publish a train schedule over the planning horizon and to analyze the impact on the resources consumed. Exhibit 5 summarizes the output of our software.

Node Node ID Num of Orig. Trains Num of Term. Trains Num of Thru Trains Num of Block Swaps Num of Block Pick ups Num of Block Set offs Num of Car Switching Average Car Dwell Time Average Loco Dwell Time Average Crew Dwell Time Total Num of Crew Starts Loco Imbalance per Day

Link Link Tail Node ID Link Head Node ID Total Train Flow

Crew Crew ID Crew Home Node ID Crew Away Node ID Total Number of Crew Starts Total Crew Deadheadings Average Rest Time at Home Average Rest Time at Away

Locomotive Total Loco Requirement Total Loco Deadheadings

Geographical Network, Crews, and Locomotives

Block Summary Block ID Number of BTAs Block Detour Number of Block Swaps Transit Time per Car Average Volume per Pick up

Shipment Shipment ID Number of Switchings Number of Swaps Detour in the Trip Total Transit Time Total Waiting Time

Shipment-Block Sequence Shipment ID Block Sequence Number Block ID

Blocks and Shipments

Train Summary Train ID Origin Node ID Destination Node ID Train Frequency Average Volume Maximum Volume

Train Route Train ID Stop Sequence Number Stop Node ID Train Arrival Day/Time Train Departure Day/Time Crew Change Flag Total Pickup Volume Total Num of Blocks

BTA Block ID BTA ID Train ID Train Seq. Number Block Pickup Node ID Block Setoff Node ID BTA Pick up Frequency

Trip Plan Shipment ID Block ID Train ID Train Operating Day Pickup Node ID Pickup Day/Time Setoff Node ID Setoff Day/Time

Model Solution
Text Color Legend: Green Input Data, Blue Output Data

Exhibit 5: Output data of the Train Scheduling Optimizer.

2. THE TRAIN SCHEDULING PROBLEM

2.4 DECISION VARIABLES

The decisions to be made by the train scheduling optimizer are: Train Routes, Timings, and Frequencies: The decisions to be made for a train schedule are: which trains to build; what is the origin, destination, and route of each train; what are the arrival and departure times of a train at the stops on the route of the train; what is the frequency of operation for a train; and on which days does the train operate. Block-to-Train Assignments by Day of Week: The cars in a block move together from the origin to the destination of the block. Therefore, the logical approach is to first decide train routes for blocks and then route shipments on trains using the corresponding block-to-train assignment. A block may be routed on multiple train paths on one day or may be routed on different train paths on different days of the week. The optimizer decides the block-to-train assignments of a block for each day of week. Shipment Trip Plan: The train scheduling optimizer also routes each shipment on the train network. As the traffic-to-block sequencing is a part of the input, the decision to be made is to choose appropriate block-to-train assignment of blocks on its route and to decide on which days of the week each shipment will be picked up by trains. Locomotive and Crew Assignments: The train scheduling optimizer also decides the assignments of crews to the trains. We consider single or double-ended crews and same crew rules in all crew districts. We also assign locomotives to trains; we assume that we have one standard locomotive type available and assign sufficient number of locomotives depending upon the number of cars or tonnages required to pull trains.

2.5 OBJECTIVE FUNCTION

The train scheduling problem is a multi-objective optimization problem and different objectives are often in conflict with one another. For example, delaying a train departure so that it can make an inbound connection minimizes car dwell time, but may increase locomotive or crew costs. Our train scheduling optimizer considers these tradeoffs and progressively includes several objective functions and multiple cost terms while designing the train schedule and trip plans such that various cost terms are balanced against one-another and the overall system-wide cost is minimum. The model considers the following weekly cost terms: Car Days and Car Miles: Car days is the total time (in days) taken by shipments from their release times at origin nodes to their arrival times at destination nodes, and car miles is the total distance traveled by shipments. Improvements in car days and car miles will reduce the ownership/hire costs of railcars, reduce yard congestion, and improve customer service.

2. THE TRAIN SCHEDULING PROBLEM

Train Starts and Train Miles: Train starts is the number of trains starting in a week and train miles is the total miles traveled by trains in a week. Reduction in both the train starts and train miles imply that the average train volume has increased and the track occupancy has decreased. Block Swaps: A block swap increases the requirement of yard resources (to transfer the block from one train to another) and the dwell time of the cars in the block. The reduction in block swaps reduces the car days and improves yard operations. Locomotive and Crew Cost: For a Class I railroad, locomotive and crew costs account for about 40% of the total operating cost. Therefore, minimizing locomotive and crew costs are important objective function terms. When solving an optimization problem with multiple objective function terms, it is desirable to reduce them to the common denomination. However, it is often difficult to quantify different cost terms and bring them to the same unit of measurement. Further, not all the objective functions play an equal role in different stages of optimization (described later in more detail). For example, train starts and train miles are important considerations while deciding the train route, whereas car days is important while deciding the train timings. Our decision support system provides the control to the users in specifying the right trade-off among different objectives in different stages of optimization by specifying different parameters. The user can set these parameters and thus control the relative tradeoff between multiple cost terms. Constraints One innovative feature of our train scheduling optimizer is its unique ability to handle numerous practical constraints and its flexibility to introduce new constraints. In this section, we describe various constraints honored by the train schedule generated. We have classified the constraints into four groups: geographical network, trains, blocks and shipments, and locomotives and crew. Exhibit 6 lists the constraints in each of these categories.

2. THE TRAIN SCHEDULING PROBLEM

Geographical Network

Restrict the number of trains originating at a node in a timewindow Restrict the number of trains terminating at a node in a timewindow Restrict the number of trains on a link in a time-window Restrict the block swaps to pre-specified nodes only Restrict the pick-ups and set-offs by passing trains at prespecified nodes Give relative preference to trains origins and destinations by node type Restrict the flow of shipments on a link by height, weight and hazmat clearance

Train

Restrict the size of a train by cars-count, length, weight, and number of blocks Restrict the stop time of a train at a node based on the work performed Restrict the speed of a train on a link Restrict the number of block destinations in a train at any point of time Restrict the number of stops of a train in its route

Shipments and Blocks

Restrict the number of block swaps in the route of a block Restrict the maximum detour of a block from the shortest path Restrict the number of pick ups of a block in a day at its origin Restrict the number of trains picking up a block at its origin in a week Ensure minimum switching time for cars at a node Ensure minimum swapping time for blocks at a node Restrict a block from setting off from a train at intermediate stop, if the train is going to the destination of the block Enforce a block to take a train, if the trains origin and destination is same as that of the block

10

2. THE TRAIN SCHEDULING PROBLEM

Locomotives and Crews

Restrict the crew changes to designated nodes only Enforce refueling of train after traveling for pre-specified number of crew districts Ensure minimum rest time for a crew at its home and away locations Restrict the train operating time of a crew to the pre-specified limit Do not change the locomotive assignment to a train at intermediate stops Ensure minimum connection times for locomotives, when they move from one train to another

Exhibit 6: Constraints honored by the train scheduling optimizer.

11

3. LITERATURE REVIEW
The train scheduling problem is a very difficult optimization problem and has remained unsolved due to its algorithmic size and complexity. Not much research has been done in the past to solve this problem. A survey paper by Assad [1980] gives the early applications of simulation and operations research techniques developed to solve the train scheduling problem. In the last two decades, few researchers have shown interest in solving the train scheduling problem. Haghani [1989] presents the formulation and solution of a combined train routing, makeup, and empty car distribution model. This formulation results in a large-scale, mixed integer programming problem with nonlinear objective functions and linear constraints. The problem is then solved using a heuristic decomposition technique. Keaton [1989, 1992] formulates the train scheduling problem as an integer programming problem and applies a Lagrangian relaxation approach along with heuristics to solve the problem. Gorman [1998] applies metaheuristics - genetic algorithms and tabu search to develop an operating plan for a US railroad. Newman and Yano [2000, 2001] solve the train scheduling problem in specific intermodal settings. Carpara et al. [2002] propose a graph theoretic formulation for the train scheduling problem using a directed multigraph. This formulation is used to derive an integer linear programming model that is relaxed using Lagrangian relaxation technique. The relaxation is embedded within a heuristic algorithm which makes extensive use of the dual information associated with the Lagrangian multipliers. This paper reports the computational results for real-world instances provided by Ferrovie dello Stato spA, the Italian railway company, and from Ansaldo Segnalamento Ferroviario SpA. Dorfman and Medanic [2004] develop a discrete event model to solve the train scheduling problem on a single track rail network. The above attempts to solve special cases of the train scheduling problem do not incorporate all the practical constraints needed in an implementable solution, nor do they consider all the important objective function terms. Thus, none of these past efforts have yielded a useful algorithm for the railroad industry. To the best of our knowledge, our solution is the first attempt to solve the train scheduling problem with realistic considerations encountered in normal business practice that incorporates car, crew, and locomotive costs in an integrated model.

12

4. A DECOMPOSITION APPROACH TO TRAIN SCHEDULING

The train scheduling problem is a very large-scale decision problem with billions of decision variables and millions of constraints. It is a common operations research practice to solve such a massively large decision problem by decomposing it into a series of smaller problems that progressively arrive at the final solution. Instead of determining the optimal values of all decision variables using a single model, we solve a sequence of smaller decision models so that the solutions of these models, when taken collectively, provide a good solution to the integrated model. Decomposition enables us to obtain very high quality solutions to intractable problems within acceptable running times. We decompose solving the train scheduling problem into the following two phases: Phase I: Train Route
Decisions: Trains and their routes Single block-to-train assignment Alternative potential block-to-train assignments Locomotive and crew assignments without time schedule

Phase II: Train Details

Decisions: Train timings Train frequencies Multiple block-to-train assignments Locomotive and crew assignments with time schedule

Exhibit 7: The two phases of the train scheduling algorithm. Phase I of the train scheduling algorithm determines train routes and block-to-train assignments (BTA) assuming that each train runs daily. The objective in this phase is to construct a set of trains so that all blocks can be feasibly carried over the train network with a minimum weighted cost of train starts, train miles, car miles, block-swaps, and locomotive and crew costs. This phase gives a primary block-to-assignment (BTA) for each block and several alterative block-to-train assignments that can also be used for this block in Phase II. Phase II takes the output of Phase I as an input and provides train details: each trains day of operations, arrival and departure times at each station, block-to-train assignments by the day of the week, and the trip plan of each shipment. The objective in Phase II is to route all the blocks and the shipments in a manner so that the total cost of operations - comprised of car days, car miles, train starts, train miles, locomotive days and crew starts - is minimal. Additional details of these two phases are described in greater detail next.

4.1 PHASE I: TRAIN ROUTE DESIGN

This phase determines train routes and block-to-train assignments assuming that each train runs daily. The objective of this phase is to construct a set of trains such that all blocks can be feasibly carried over the train network. The following exhibit captures the essence of the algorithm for the train route design module.

13

4. A DECOMPOSITION APPROACH TO TRAIN SCHEDULING Construction Inputs Design train routes and assign blocks to trains. Improvement Improve the block-to-train assignments. Output

Exhibit 8: Overview of the train route design phase. We next describe the details of these modules. Construction: The construction algorithm iteratively builds trains and assigns blocks to the train built. While designing trains, the following criteria are considered: (i) blocks can have at most one block-swap; (ii) trains are filled to their capacities; (iii) trains are uniformly loaded over their entire route; (iv) trains must have valid crew routes; and (v) train routes encourage locomotive and crew balance. In each iteration, this routine enumerates tens of thousands of potential crew friendly routes (including multiple routes between the same origin-destination pair), assigns available blocks to each route, and evaluates the efficiency of the route using a weighted sum of the objective function terms described above. The relative weights for these terms can be controlled by the user. Improvement: The improvement algorithm takes as an input a set of train routes with blocks assigned to them and attempts to improve the block-to-train assignments. It iteratively reassigns the blocks to different trains to improve the overall objective function. This algorithm uses a very large-scale neighborhood (VLSN) technique to identify fairly sophisticated improvements. We refer the reader to the papers by (Ahuja et al. [2001a, 2001b, 2002a, 2000b, 2003a, 2003b, 2003c, 2004a, 2004b, 2004c, 2004d, 2005]) for more details of VLSN search techniques. One of the main objectives in this routine is to distribute the load among trains more uniformly along their routes.

4.2 PHASE II: TRAIN DETAILS DESIGN

This phase takes the output of Phase I as its input and provides train details as an output: each trains day of operation, arrival and departure times at each station it visits, block-to-train assignment by the day of the week, trip plan of each shipment, and locomotive and crew assignments. This phase is fairly complex since it deals with each shipment on a car level, each train on the day of the week level, and also takes into account the locomotive and crew requirements, again on the weekly level. In the following discussion, we refer to a train operating on a specific day of the week as a train leg.

14

4. A DECOMPOSITION APPROACH TO TRAIN SCHEDULING

This phase first constructs the seven-day space-time train network and then executes the following three modules repeatedly until convergence:

Time Optimization Inputs Decides the arrival and departure time of each train at each stop.

Freq. Optimization Decides the days of operation of each train.

BTA Optimization Decides block-totrain assignments of each block by the day of the week.

Outputs

Iterate until convergence

Exhibit 9: An overview of the train details design phase. Train Time Optimization Module: This is a very sophisticated module as it determines the impact of a train departure time on three important statistics: car days, locomotive cost, and crew cost. In this algorithm, we iteratively optimize the departure times of trains at their origins. For each train, we consider all the possible departure times and determine the best time that will minimize the railcar, locomotive, and crew costs. This algorithm constructs three networks: (i) a seven-day train network in which cars flow according to their trip plans; (ii) a locomotive network where locomotives flow to meet train power requirements; and (iii) a crew network where crews are assigned to trains. All three networks are seven-day space-time networks. Each time a train departure time changes, flows of cars, locomotives, and crew in their respective networks are reoptimized to assess the impact of this change. This algorithm determines locally optimal train departure times. Train Frequency Optimization Module: Train frequency optimization module attempts to delete low volume train legs and assesses the impact of this deletion on car days and train miles. In each iteration, it considers a set of lowest volume train legs and considers them for potential deletion and the train leg whose deletion results in the maximum savings is deleted. This module also considers addition of train legs that result in maximum cost savings. Observe that if the algorithm deletes train legs, then train miles, locomotive requirements, and crew requirements decrease but car days increase. Similarly, when the algorithm adds train legs, then car days decrease, but other costs increase. Block-to-Train Assignment Optimization Module: Recall that Phase I (train route optimizer) provides a primary block-to-train assignment (BTA) for each block as well as several alternative BTAs. In this module, the algorithm attempts to identify the optimal BTAs for each block, considering all of its BTAs. The module considers each block oneby-one, enumerates all the possible choices of BTAs available, assigns the traffic in the block to the selected BTAs, and assesses the impact on car days. The set of BTAs which minimize the car days is selected.

15

4. A DECOMPOSITION APPROACH TO TRAIN SCHEDULING

To summarize, the algorithms used in train scheduling software are very sophisticated and computationally intensive algorithms. Our algorithms utilize state-of-the-art optimization and implementation technologies. We have used highly efficient data structures to implement these algorithms so that the running times are reasonable. We have also used numerous ideas from network flow theory (see Ahuja, Magnanti and Orlin [1993]) to speed up various tasks. Our current algorithm takes about an hour to determine the train schedule on a workstation.

4.3 INTEGRATING RAILCAR, CREW, AND LOCOMOTIVE CONSIDERATIONS IN TRAIN SCHEDULING

The unique feature of our algorithmic approach is that we optimize three important resources, railcars, crew, and locomotives in an integrated manner. However, considering these three resources in a unified manner poses some computational challenges. Just optimizing each of these resources on the network level separately is already a very large scale and complex optimization problem. Optimizing these resources together increases its complexity multifold since each resource flows over its network: locomotives flow from node to node in the entire network, whereas crew move over their respective crew districts. In addition, costs of these resources are conflicting. If we add new train legs, we reduce railcar costs but typically increase crew and locomotive costs. If we delete trains, we reduce crew and locomotive costs, but may increase car block swap costs. Indeed, optimizing the costs of three different resources in an integrated manner has been our most significant contribution. We accomplish this integration by creating three seven-day space-time networks: car flow network, crew flow network, and locomotive flow network. Each decision made in our algorithm about train routes, train frequencies, train timings, and block-to-train assignments impacts the flow of resources in these three networks. We determine the net impact of each decision and take optimal decision that minimize the total system-wide costs.

16

5. INCREMENTAL TRAIN SCHEDULING

Our train scheduling optimizer can generate a brand new, clean-slate train schedules for a railroad, which include new trains, new train routes, new frequencies, new block-totrain assignments, and new arrival/departure times. While this new train plan optimizes system-wide costs including minimizing car time, crew costs, and locomotive costs; a brand new train schedule is difficult to implement as it might require a complete change of virtually every business process within a railroad company. The implementation of a clean-slate train plan might require revamping of field operations, crew management, empty car management, and locomotive management. Additionally, railroads have commitments to customers and other railroads which dictate certain aspects of the train schedules. Thus, railroad companies seldom implement a completely new set of train schedules. However, railroad companies frequently adjust their current train schedules to accommodate new flows and shrink capacity where appropriate to save costs. Consequently, we have enhanced our train scheduling optimizer to be an effective decision support tool for aiding service designers in making controlled incremental changes to their current train schedule plan. The incremental train scheduling consists of identifying incremental changes in the current train schedule which have the greatest impact on the total cost. Some examples of incremental changes are: changing the routes, timings, and frequencies of trains only originating at a node; changing the blockto-train assignments of only a few blocks; changing the days of operation of a few trains, etc. The advantages of this incremental approach include: (i) easier transition for field operations managers; (ii) rapid response to changing traffic demand; (iii) minimal network disruptions; and (iv) better control of model behavior. Our incremental train scheduling optimizer gives enormous flexibility to the user in terms of specifying what changes can be made in the given train schedule. An example of user-defined incremental train scheduling will be the following: Delete at most 5% of the existing trains, create at most as many new trains as deleted, change block-train assignments of a minimum number of blocks, and achieve maximum system-wide savings. The train scheduling problem has four entities, and the user can specify the extent of changes that can be made in any of these entities; Exhibit 10 shows the changes a user can specify.

17

5. INCREMENTAL TRAIN SCHEDULING

Entity Specifying the Extent of Changes in Existing Train Schedule Geographical Network Change blocks and/or trains originating and/or terminating only at a specified set of nodes Do not increase work at some nodes (that is, pick ups, set offs, and block swaps) Allow changes at specified nodes or all nodes of a particular yard type

Trains

Fix the train routes of some train types Do not delete trains in a specified set Do not introduce new work stations on the route of a set of trains Do not change timings and/or frequency of some trains Partially fix the blocks and/or shipments assigned to some trains

Blocks

Do not change the block-to-train assignment of some blocks Do not introduce block-swaps in the route of some blocks Limit the number of block-to-train assignments of blocks Partially fix block-to-train assignment of blocks Restrict the changes in block-to-train assignments by specified business rules

Shipments

Do not change trip plans of some shipments Change trip plans of shipments only if the change results in improvement in transit time, not otherwise Prohibit some shipments to ride on certain trains Limit the average dwell time of traffic at origin and/or intermediate stations by pre-specified durations

Exhibit 10: Specifying the extent of changes in incremental train scheduling.

18

5. INCREMENTAL TRAIN SCHEDULING

The incremental train scheduling algorithm uses the same modules as used by the clean-slate train scheduling algorithm. However, we do some pre-processing to determine the degree of freedom available to the optimization modules. If incremental change allows changing train routes, then we invoke train route optimization, not otherwise. If we do not change train routes but change only the train timings, train frequencies, or fine-tune block-to-train assignments by the day of the week, then we invoke only the train details optimizer. Further, in this case, we invoke only the module that is needed. For example, if a user wants to optimize only the train timings, then we invoke only the train timing optimization module. If a user wants to optimize train frequencies or wants to optimize block-to-train assignments, then only the appropriate routines are invoked. If the user wants to optimize all three variables, then all the three modules are executed. Thus, depending upon the degree of freedom allowed, appropriate modules are called and the necessary decision variables are optimized.

19

6. A DECISION SUPPORT SYSTEM FOR TRAIN SCHEDULING

The execution of a train schedule impacts the routings of loaded/empty cars, yard operations, crew assignments, locomotive assignments, and track utilization. This impact must be very carefully analyzed before implementing the train schedule. We have thus packaged our train scheduling optimizer engine within a Microsoft Access-based decision support system that enables a user to store the data, review the input, adjust parameter settings, run our optimizer engines, analyze the output, and perform a detailed comparison of two train scheduling solutions (given and new). Exhibit 11 presents the architecture of our train scheduling decision support system.

Train Route Optimizer Train Details Optimizer

Railroad Data

Input

Train Scheduling Decision Support System

Exhibit 11: system.

The architecture of our current train scheduling decision support

Our decision support system has the following functions: It takes the text files as an input, performs data conversion, and stores it in a database. As a byproduct, it also generates the input data error report. It enables users to input parameter values and specify the extent of changes in the current schedule. It then executes train route optimizer and train details optimizer and stores the output in a database. It processes the output of the train details optimizer and prepares detailed reports on: (i) train routes, timings, and frequencies; (ii) trains statistics by day of the week; (iii) blocks assigned to a train; (iv) block-to-train assignment of blocks by day of the week; (vi) activities performed at yards by day of the week; and (vii) imbalances in stations in the network. The decision support system also performs a detailed comparison of the given train schedule and the new train schedule. Exhibit 12(a) lists the primary interfaces in our current train scheduling DSS, and Exhibit 12(b) displays two sample screenshots of the train scheduling decision support system. While comparing two solutions, it also sets the flags in the database which enables users to easily identify the trains, blocks, and nodes where changes have been made in the train schedule.

20

6. A DECISION SUPPORT SYSTEM FOR TRAIN SCHEDULING

Form Function Navigation among different forms in the DSS Navigation Menu Separate tabs to navigate comparison analysis, detailed analysis for the railroad solution, and the model generated solution

Solution Summary

Overall statistics of two train scheduling solutions Several histograms comparing quality of the solutions

Train Comparison

Side-by-side comparison of trains and their characteristics in two train scheduling solutions Comparison of the routes and blocks riding on a selected train in two train schedules

Block Comparison

Side-by-side comparison of blocks assignments in two train schedules

and

their

block-to-train

Comparison of block statistics and its shipments grouped by their origins and destinations Node Comparison Node Congestion

Comparison of activities at a node in two train schedules

Graphical comparison of the number of trains originating and terminating at a node by the day of week in two train schedules

Train Details

Detailed analysis of a train in a solution by the day of week, by the blocks , and by the stops in its route

Block Details

Detailed analysis of pick up and setoff locations of a block by the day of week in a train schedule (a)

21

6. A DECISION SUPPORT SYSTEM FOR TRAIN SCHEDULING

Exhibit 12: (a) Forms in the current train scheduling decision support system. (b) Two sample screenshots of the train scheduling DSS.

22

7. COMPUTATIONAL RESULTS
We have implemented our optimizer engines in C++ and they can run efficiently on a workstation or a laptop computer. We have applied our train scheduling optimizer to the data provided by two US Class I railroads in both the clean-slate and incremental modes. The running time of our optimizer is very reasonable and we can determine train schedules within an hour. Our solutions are going through preliminary testing by the service design personnel for impementability and their response is very encouraging. In the coming months, we plan to perform thorough computational studies for US railroads and will report the results of these studies in a later version of this paper.

23

8. A WEB-BASED TRAIN SCHEDULING DECISION SUPPORT SYSTEM

Our current decision support system for train scheduling is an excellent start to solve an important service design problem that had defied a solution so far. We are currently enhancing this system into a commercial-grade, highly interactive, web-based decision support system which would give a user much broader capabilities than the current system allows. The table shown in Exhibit 13 presents the highlights of this decision support system.

24

8. A WEB-BASED TRAIN SCHEDULING DECISION SUPPORT SYSTEM

Feature Description A web-based decision support system built using latest information technology tools Web-Enabled System Built upon optimization engine developed in C++, SQL Server as the DBMS, and interfaces developed using VB .NET 2.0 and ASP .NET 2.0 Geographical interfaces also available

Can store and analyze multiple train schedules in the form of different scenarios Scenario Management Enables a detailed comparison of any two scenarios Allows different types of users with different privileges

Data Analysis

Using a data bridge, the railroad data can be imported into the decision support system and the optimized solution can also be exported to the railroads information system Provides a platform to analyze and modify input data and specify various parametric settings

Enables users to run different modules of the train scheduling optimizer Interactive Optimization Users can rerun the modules by fixing/eliminating some decision variables and also manually fine-tune the solution

A detailed solution analysis of all entities available to the user including nodes, links, trains, blocks, and shipments Solution Analysis Detailed summary statistics also available, including charts Web-based system allows the data and solution to be viewed by field personnel and executives using a web-browser

25

8. A WEB-BASED TRAIN SCHEDULING DECISION SUPPORT SYSTEM

Highly flexible environment for a user to customize views of various web pages, forms, and reports Expandable/collapsible forms and sub forms to allow a user to focus on the desired information User Customization Powerful multi-criteria filtering and multi-criteria sorting to identify relevant records Enables users to enter and store comments for any node, link, train, block, and shipment

Exhibit 13: Salient Features of Web-based Train Scheduling Decision Support System. An important advantage of the web-based decision support system is the ease with which the softwares result can be shared with field personnel. A service design user, who understands the model, can run the model, create a scenario, and email field personnel the link to the scenario. The decision support system provides detailed analysis tools and drill-down capabilities which field personnel can use to study the scenario in great detail, compare the current train plan with the new train plan, and convey their feedback to the service design. The service design user can quickly create another scenario incorporating this feedback, and give field personnel another solution to study. Thus, a good train plan which is acceptable to the field personnel can be created within a few iterations, without any need for personnel to make personal visits to the service design headquarter. This not only saves cost, but also saves valuable time for the field personnel. In addition, our decision support system would allow users the ability to fine-tune a train schedule, for example reassigning blocks from one train to another train as well as changing train frequencies and train timings. We also plan to add a geographical information system (GIS) to our decision support system and show data and solutions on railroad networks drawn on a map.

26

9. AN INTEGRATED SOFTWARE SUITE FOR SERVICE DESIGN

We plan to build a web-based, integrated suite of software for railroad service design that would integrate our blocking optimizer with the train scheduling optimizer. We give the architecture of our integrated service design suite in Exhibit 14.

Transportation and Operations Managers

Innovative Web-Based Service Design Suite Blocking Decision Support System Train Scheduling Decision Support System

Feedback

Data Bridge

Railroads Information System

Exhibit 14: The web-based decision support system for service design. A typical service design operating plan is comprised of designing the blocking plan followed by designing a train schedule. The train schedule design takes the blocking plan as an input and routes the blocks over the trains that are built. Our integrated suite for service design will provide an integrated platform to perform both the blocking and train scheduling. This integration serves a very useful purpose. As mentioned earlier, the blocking plan is an input to the train schedule design. However, as we build the train schedule, some blocks may not be train friendly, and if we replace those blocks with other blocks, we will be able to build more efficient train schedules. This flexibility will enable us to change the blocking plan to build better train schedules, adding a new dimension to the service design and greatly increasing the attractiveness of our software for railroads. However, building this feature requires interactions between the decision support systems for blocking and train scheduling. The decision support system for train scheduling will give its input to the decision support system for blocking so that it generates train-friendly blocks. Decision support systems for blocking will generate blocks that can be easily routed over the trains. The integrated service design suite would make generating blocking plans and train schedules seamlessly easy.

27

9. AN INTEGRATED SOFTWARE SUITE FOR SERVICE DESIGN

The integrated suite for service design will significantly speed-up the operating plan design process of railroads. Currently, the clean-slate operating plan design process at Class I railroads takes three to six months and incremental changes to the operating plan take at least one month. Creating clean-slate schedules also requires active participation by a number of experienced service designers. Using our integrated suite, we expect that the clean-slate operating plan can be developed within two to three weeks and incremental changes to the operating plan can be done within a week.

Clean-Slate Blocking Plan Design

Solve infrequently or for special studies

Clean-Slate Train Schedule Design

Incremental Blocking Plan Design

Solve periodically

Incremental Train Schedule Design

Exhibit 15:

Use of service design software suite for railroads.

Availability of this software suite and the ability to develop new operating plans will quickly make a railroad more responsive to traffic changes. As traffic shifts take place from month to month or from one season to another, railroads continuously strive to update their operating plans; but the current manual process often results in a futile exercise where the planners are constantly trying to catch-up with the reality in the field. Our tool will ensure that the plans are current and optimal. Optimal and timely plans will introduce greater efficiency in the system, better utilization of railcars, crews, and locomotives. We also anticipate our algorithmically generated plans to reduce costs compared to the manually generated operating plans.

28

SUMMARY AND CONCLUSIONS

ACKNOWLEDGEMENTS
The work reported in this paper has been supported by BNSF Railway and the National Science Foundation Small Business Innovations Research (SBIR) grants: DMI-0441297 and DMI-0548666. We gratefully acknowledge the support of our sponsors. We thank Larry Shughart (Innovative Scheduling), Ron Griffith (BNSF Railway), Marty Schlenker (BNSF Railway), and Bryan Medart (BNSF Railway) for their insightful comments and constructive suggestions.

REFERENCES
Ahuja, R.K., T.L. Magnanti, and J.B. Orlin. 1993. Network Flows: Theory, Algorithms, and Applications. Prentice Hall, NJ. Ahuja, R.K., J.B. Orlin, and D. Sharma. 2001a. Multi-exchange neighborhood structures for the capacitated minimum spanning tree problem. Mathematical Programming 91, 71-97. Ahuja, R.K., J. Goodstein, A. Mukherjee, J.B. Orlin, and D. Sharma. 2001b. A very largescale neighborhood search algorithm for the combined through-fleet assignment model. To appear in INFORMS Journal on Computing. Ahuja, R.K., O. Ergun, J.B. Orlin, and A.P. Punnen. 2002a. A survey of very large-scale neighborhood search techniques. Discrete Applied Mathematics 123, 75-102. Ahuja, R.K., K.C. Jha, J.B. Orlin, and D. Sharma. 2002b. A very large-scale neighborhood search algorithm for the quadratic assignment problem. Submitted to INFORMS Journal on Computing. Ahuja, R.K., J.B. Orlin, and D. Sharma. 2003a. A composite very large-scale neighborhood structure for the capacitated minimum spanning tree problem. Operations Research Letters 31, 185-194. Ahuja, R.K., J. Liu, J. Goodstein, A. Mukherjee, J.B. Orlin, and D. Sharma. 2003b. Solving multi-criteria combined through-fleet assignment models. A chapter in the book Operations Research in Space and Air, Edited by Tito A. Ciriani, Giorgio Fasano, Stefano Gliozzi, and Roberto Tadei, Kluwer Academic Publishers, pp. 233-256. Ahuja, R.K., A. Kumar, K.C. Jha, and J.B. Orlin. 2003c. Exact and heuristic algorithms for the weapon-target assignment problem. Submitted to Operations Research. Ahuja, R.K., J. Liu, J. Goodstein, A. Mukherjee, and J.B. Orlin. 2004a. A neighborhood search algorithm for the combined through and fleet assignment model with time windows. Networks 44, 160-171.

29

SUMMARY AND CONCLUSIONS

Ahuja, R.K., J.B. Orlin, S. Pallottino, M.P. Scaparra, and M.G. Scutella. 2004b. A multiexchange heuristic for the single source capacitated facility location. Management Science 50, 749-760. Ahuja R.K., K.C. Jha, and J. Liu. 2004c. Solving real-life railroad blocking problems. Working paper, Department of Industrial and Systems Engineering, University of Florida, Gainesville, FL. Ahuja R.K., B. Vaidyanathan, and K.C. Jha. 2004d. New algorithms to solve railroad crew scheduling problem. Working paper, Innovative Scheduling inc., Gainesville, FL. Ahuja, R.K., J. Liu, J.B. Orlin, D. Sharma, and L.A. Shughart. 2005. Solving real-life locomotive scheduling problems. Transportation Science 39, 503-517. Assad, A.A. 1980. Models for rail transportation. Transportation Research 14A, 205-220. Carpara A., M. Fischetti, and P. Toth. 2002. Modeling and solving the train timetabling problem, Operations Research 50. 851-861. Dorfman M.J., and J. Medanic. 2004. Scheduling trains on a railway network using a discrete event model of railway traffic, Transportation Research (B) 38. 81-98. Gorman, M.F. 1998. The freight railroad operating plan problem. Annals of Operations Research 78, 51-69. Haghani A.E. 1989. Formulation and solution of a combined train routing and makeup, and empty car distribution model. Transportation Research 23B, 433-452. Keaton M.H. 1989. Designing optimal railroad operating plans: Lagrangian relaxation and heuristic approaches. Transportation Research 23B, 415-431. Keaton, M.H. 1991. Service-cost tradeoffs for carload freight traffic in the U.S. rail industry. Transportation Research 25A, 363-374. Newman, A.M., and C.A. Yano. 2000. Direct and Indirect Trains and Containers in an Intermodal Setting, Transportation Science 34, 256-270. Newman, A.M., and C.A. Yano. 2001. Scheduling trains and containers with due dates and dynamic arrivals, Transportation Science 35, 181-191. Vaidyanathan, B., R.K. Ahuja, Jian Liu, and L.A. Shughart. 2006. Real-life locomotive planning: New formulations, algorithms and computational results. Technical Report, Innovative Scheduling, Inc., Gainesville, FL.

30

SUMMARY AND CONCLUSIONS

ABOUT THE AUTHORS

Ravindra K. Ahuja, President & CEO of Innovative Scheduling, Inc., specializes in mathematical modeling, state-of-the-art optimization techniques, and sol ving large-scale scheduling problems arising in logistics and transportation. He holds a joint appointment as a Professor of Industrial & Systems Engineering and Co-Director of Supply-Chain and Logistics Engineering (SCALE) Center at the University of Florida, Gainesville. Professor Ahuja has over 25 years of academic, research, and consulting experience. He founded Innovative Scheduling (www.InnovativeScheduling.com) in order to bring cutting-edge operations research and optimization techniques to the field of transportation. He has developed innovative models and algorithms for several complex airline scheduling, railroad scheduling, and logistics problems that were previously considered intractable. He is a coauthor of the book, Network Flows: Theory, Algorithms, and Applications, jointly with T.L. Magnanti (MIT) and J.B. Orlin (MIT). This book is now the leading text and reference book in the field of network optimization and won the prestigious Lanchester Prize in 1993, given annually to the best publication in operations research. He is now coauthoring two textbooks on developing decision support systems. Professor Ahuja publishes widely in prestigious research journals and is an Associate Editor of the two journals: Transportation Science, and Networks. Pooja Dewan, Technology Services, BNSF Railway, specializes in mathematical modeling, and algorithmic design and development. She is currently employed with BNSF Railway as a Manager for the Operations Research group. During her seven years with BNSF, Pooja has worked as an internal consultant with several groups including Fuel, Service Design, Engineering, E-business, Marketing, Service Support and Operations. During these engagements, she has assisted these groups in building optimization based tools that could help attain improved efficiencies. She has been the Chair of Rail Application Special Interest Group (RASIG) of INFORMS (Institute for Operations Research and Management Science) for the year 2003-2004. Dr. Dewan is the author of several research publications that appeared in various scientific journals. Mohammad Jaradat, Software Analyst at Innovative Scheduling, specializes in software design, development and engineering using latest information technology tools. His breadth of knowledge encompasses a variety of developmental environments and programming languages; including Visual Basic .NET, Visual C# .NET, Visual C++, ANSI C/C++, and Java. Mr. Jaradat is leading the database design and the user interface development for the Innovative Train Scheduling Optimizer software. He is also leading a team to develop a GIS-based web-enabled tool, Innovative Network Flow Analyzer, which enables users to analyze market data and freight flows. This software deploys a suite of highly sophisticated network optimization algorithms at the backend. Mr. Jaradat has three years of industry experience as a software developer and engineer at SEDCO, Jordan and ESTARA, Jordan. At SEDCO and

31

SUMMARY AND CONCLUSIONS

ESTARTA, he worked on embedded systems solutions; instant messaging logging; and bi-directional, bi-lingual (Arabic and English), smart SMS-enabling engine. While studying at the University of Florida, he worked on developing case studies for a VB.NET and ASP.NET book. Mr. Jaradat is a recipient of prestigious Fulbright Scholarship and he has been recognized by the Jordanian royal family for his academic excellence. Krishna C. Jha, Director of Research and Development at Innovative Scheduling, specializes in mathematical modeling, state-of-the art optimization techniques, algorithmic design and development, and software engineering. Dr. Jha has over ten years of experience in industry, consulting, and academia. During his doctoral studies, he developed innovative very large-scale neighborhood search algorithms for several optimization problems arising in facility planning, defense, and railroad scheduling. His research on the Block-to-Train Assignment Problem won him the First Prize in 2003 INFORMS paper competition on Management Science in Railroad Applications. Currently, Dr. Jha is the Lead Development Manager of our three forthcoming software products - Train Scheduling Optimizer, Crew Scheduling Optimizer, and Dynamic Trip Planner. Prior to joining Innovative Scheduling, Dr. Jha utilized his expertise for four years at the largest private steel producer in India, Tata Steel, where he worked in a variety of areas, including workforce planning, incentive planning, performance improvement, benchmarking, capital schemes evaluation, supply-chain management, total quality management, and knowledge management. Throughout his career at Tata Steel, he championed the application of industrial engineering tools to business problems. At Tata Steel, Dr. Jha has also served as an internally certified auditor of ISO 9000 and ISO 14000. Arvind Kumar, Director of Research & Development at Innovative Scheduling, specializes in mathematical modeling of complex real-life decision problems using state-of-the-art operations research techniques including linear programming, integer programming, network flows, and heuristics. He is a key member of the team developing the train scheduling decision support system. He is also the Lead Development Manager for our forthcoming software products on meet-pass planning and hump yard management. Besides his interest in transportation, Arvind has made significant contribution to the ongoing research in the field of radiation therapy. With his collaborators at the University of Florida, he developed very efficient algorithms to solve these problems which will reduce the current patient treatment time significantly while simultaneously improving the treatment quality. His doctoral dissertation focused on the development of linear programming approaches for radiation therapy treatment planning problems. At the 2003 INFORMS Annual Meeting, his coauthored paper, "A column generation approach to radiation therapy treatment planning using aperture modulation," won the prestigious Pierskalla Award given to the best paper in Health Applications.

32

SUMMARY AND CONCLUSIONS

ABOUT INNOVATIVE SCHEDULING

Innovative Scheduling, Inc. is engaged in developing large-scale computer models to help transportation industry executives analyze and optimize complex planning and scheduling problems. We are building a diverse team of industry experts, software engineers, researchers, and leading academicians. We are expert in optimization and simulation techniques, and packaging these techniques using the latest information technology tools. We specialize in developing very efficient, responsive, interactive, and user-friendly software solutions to decision problems resulting in substantial benefits for our clients. Our team of experts is also available for consulting engagements. We provide consulting in systems design, economic analysis, forecasting, and capital investments. Additional information about us can be found at the website: www.InnovativeScheduling.com. We have developed several software products for railroads which include: Innovative Railroad Blocking Optimizer Innovative Train Scheduling Optimizer Innovative Locomotive Optimizer Innovative Hump Yard Manager Innovative Network Flow Analyzer Innovative Meet-Pass Planner Innovative Crew Optimizer Innovative Network Configuration Optimizer

These software products ideally qualify us to provide consulting services for railroads that requires sophisticated quantitative analysis. If you are interested in our products or services, please contact either of the following: Ravindra K. Ahuja, President email: ravi@InnovativeScheduling.com phone: (352) 870-8401 Larry Shughart, Vice President email: larry@InnovativeScheduling.com phone: (352) 284-1250

33