6.6.1 The Relevance of Mass Transit Experiences
The term Mass Transit is generally used to encompass urban public transport
operations, be they road (‘bus) or rail (tram, train or underground/subway). These are substantial undertakings with often many hundreds or even thousands of vehicles, many more staff and a complex network of connecting services.
To what extent are mass transit operations comparable with railways and therefore of relevance to this thesis? Similarities include the need to schedule vehicles and people, often based at a number of depots and, for the rail mode, to manage infrastructure capacity issues. The basic rules for scheduling vehicles and people are inevitably virtually identical, although there are typically more, and more complex, rules that apply to railway operations and, hence, findings should be transferrable to ‘main line’ railways.
More obvious differences include the absence of freight traffic from mass transit
operations and the greater distances and often greater network complexity of ‘main line’
railway operations.
6.6.2 Mass Transit User Needs
The proceedings of the Computer Aided Transit Scheduling conferences, more recently titled Computer-Aided Scheduling of Public Transport (Daduna and Wren, 1990,
Rousseau, 1992, Daduna et al., 1995, Wilson, 1999, Voss and Daduna, 2001) provide rich coverage of the state of development of software to support mass transit scheduling.
Hoffstadt (1990, at the 1988 conference) considered management and planning staff objectives. He found that management wants to reduce subsidies, reduce operating costs or run more services for a given cost whilst planning staff want help with handling time-consuming routine work to give time to process short term changes more
effectively.
Elms (1990), describing the experiences of London Buses, noted that scheduling expertise is a key driver in controlling staff costs and observed that larger benefits can be derived from tackling the schedule optimisation problems than data transfer and management - because improvements in scheduling have greater ‘leverage’, attacking the much larger operating staff cost rather than the relatively small scheduling team.
However, he conceded that addressing the support functions first may be ‘quicker and cheaper’ and he indicated that, when addressed, substantial staff savings can be made.
Reporting on the successful implementation of scheduling software at SEMTA (Southeastern Michigan Transportation Authority) Campbell (1990) set out some features that the software needs to have, including speed of processing, so that the scheduler does not have to wait for background tasks to complete, and a high quality graphical interface. He notes that schedulers have good reasons for tending to use large pieces of paper for manual scheduling.
Wallace (1995) set out what drove London Underground to invest in computer
scheduling. The driver for software development here was very different to the previous reviews: automated signalling systems needed train service data to feed them; this data in turn needed to be error and conflict free. Hence error and conflict detection software was in place before schedule edit and generation programmes.
A common thread through these papers is that the speed of processing and efficiency of the resulting schedules are key drivers in the introduction of scheduling software.
Another common thread is that basic ‘support functions’ are best encompassed first (Elms 1990) with automation of scheduling functions coming later.
This matches well the priorities of train planners as set out in the last section.
6.6.3 Mass Transit and ‘Main Line’ Train Planning Software Compared
The close parallels between mass transit and railways would lead one to expect that
scheduling software would develop in parallel. The extent to which this is true is now considered.
Daduna and Pinto Paxao (1995) noted that, for mass transit scheduling, initial effort (in the 1960s) focused on data processing, with schedule generation and optimisation not gaining wide acceptance due to the processing limits of the computers of the time and the limited effectiveness of the algorithms. They also noted that a three stage process needs to be supported (preparation, automatic scheduling and interactive alteration, graphic and alpha-numeric). Hoffstadt (1990) predicted that major areas for software development would be (and indeed were) in the provision of user-friendly interfaces, data management systems and computer networks.
Today, mass transit scheduling software such as HASTUS (Giro, 2007) and Trapeze (Trapeze, 2007) provides considerable support for mass transit schedulers, including automated schedule generation and optimisation. Development is now extending into
‘real time’ scheduling. This compares with railway scheduling, where optimisation tools are only just beginning to be developed and much software development effort is still being spent on improving more basic data manipulation and edit functions. It is clear that mass transit scheduling has become far more automated than railway scheduling (c.f. Borndorfer et al., 1998).
Cordeau et al. (1998) suggest that solutions currently offered for rail have tended to lack realism. Wren and Rousseau (1995) assert that the complicated rules that are so much more prevalent in railway scheduling problems have a profound effect and note that, for many specific railway problems, modification to the basic algorithm is needed to produce a satisfactory solution (see also Ferriera, 1997). This is particularly true in the area of timetabling, where rail networks are very significantly more complex than mass transit networks. Wren also notes that changing rules are a particular problem where
algorithms have, of necessity, been adapted to particular circumstances.
Cordeau et al. also suggest that there has been a lack of urgency within railways to improve efficiency and hence spend money on scheduling software.
A significant feature of the railway software development scene is that it is very
fragmented, with most railways having their own bespoke software. This can be contrasted with the more successful mass transit scheduling packages, which have a very wide international customer base, with the opportunity to share specification, development and testing costs.
Overall it is apparent that railway scheduling software development is some years behind mass transit scheduling software. There are a variety of reasons for this, including the complexity of the problem, the commitment of the railway industry to use advanced algorithms and the software supply industry structure.
6.7 Conclusions
It is clear that there is a considerable need for improved software to support train
planning processes. Even basic data management tasks are not fully automated, whilst more sophisticated tools which could generate solutions and potentially optimise them too are considered a ‘pipe dream’.
Whilst it would have been interesting and valuable to explore all of the areas of potential software development set out in earlier sections it has been necessary to be selective for reasons of time.
The investigation of how to enhance the basic data management software to better support the needs of train planners has not been pursued because this does not require substantial research – it requires detailed specification, software coding and
implementation. At the other end of the requirements list, the development of process-wide optimisation tools that integrate timetabling, rolling stock diagramming and train crew diagramming, looking to optimise across these tasks, is dependent on, firstly, being able to construct software that reliably produces software for the individual process steps. As tools to do this do not currently exist, there is no adequate base on which to develop these tools at present.
This leaves simulation and timetable generation and optimisation as two key areas where research could help hasten their deployment and hence these areas are explored in the following chapters.
7 USE OF HEURISTICS IN TIMETABLE GENERATION AND OPTIMISATION
7.1 Introduction
This chapter has as its focus the use of expert systems and, in particular, heuristics in timetable generation and optimisation.
This is not an Operations Research thesis and, hence, discussion of the principles of heuristics and their development is restricted to a high level description of the nature of the timetabling problem from an operations research prospective and a literature review of research work in the area of heuristics as applied to timetabling. This is provided as background to the discussion, from a business perspective, of timetable generation and optimisation.
Following sections on research method and literature, the bulk of this chapter is
concentrated on analysing the only heuristic-based tool currently available in Britain, the Planning Timetable Generator, and analysing the extent to which it is ‘fit for purpose’, in the sense that it usefully supports train planners in meeting the objectives they are set and where improvements need to be made. In particular, it is necessary to consider the extent to which the software offers:
• A worthwhile reduction in timetable development timescales;
• Facilitation of the assessment of a wide range of timetables;
• Facilitation of the assessment of the feasibility of a range of different commercial specifications over a variety of different possible future infrastructures.
Much of this chapter has been peer reviewed prior to presentation at conferences (Watson et al., 2000; Watson, 2003; Watson, 2006).