6.5.1 Interview Results
Typically (but not necessarily obviously) train planners do not ask for support in solving conflicting requirements and optimising resource utilisation (that could in theory be solved by a ‘generator’ or ‘optimiser’) but rather ask for help with the elimination or reduction of the repetitive data manipulation tasks that delay them from tackling the
‘interesting’ conflict resolution and optimisation work.
Thus the avoidance of data re-keying between systems is a primary requirement, followed by support for data formatting and preparation (e.g. producing the printed timetable at the end of the process) and then better visualisation of train schedules, preferably with ‘interactive graphical edit’ to enable the planner to move around lines that represent train services on screen and see the effect on other services immediately.
Next in priority for help comes ‘error detection’ and ‘conflict detection’, i.e. showing where intervention is necessary.
Train planners rarely asked for robustness checking software or optimisation software which might help them achieve more complete conflict resolution, resource cost minimisation or reliability improvement. When prompted, they were sceptical about whether this was technically feasible and noted that a software tool that produced a
‘90%’ solution would be of little use, as it might be necessary to start again from scratch to develop a full solution.
The priorities for software support derived from interviews with train planners are set out, ranked, in the table below, together with key issues raised.
Table 6: Train Planners’ Priorities for Software Support (Source: Author)
TRAIN PLANNER REQUIREMENTS
ISSUES
1. Avoidance of data rekeying Users are currently rekeying in a number of areas (e.g. engineering work, train and infrastructure performance
characteristics). However, if they do not rekey, they need output that confirms data quality and provides analysis of data imported
2. Data preparation and access Need simple ways of coping with different ‘days run’ scenarios (minor differences due to Bank Holidays and engineering work, which can lead to an explosion of data)
3. Data formatting (e.g. printed timetable preparation)
Old systems exist which are largely satisfactory in terms of the quality of output, although somewhat laborious to use – including not being ‘WYSIWYG’
(what you see is what you get). The key problem is keeping in step with late changes made in ‘up stream’ systems 4. Schedule edit/visualisation Existing systems have problems with
graphical representation of complex infrastructure (e.g. parallel running lines, major junctions).
Existing systems also have a major problem with speed of drawing train graphs on screen (can take several minutes for even a small geographic area, partly due to network speed but also to inherent weaknesses in the
software design)
5. Schedule error/conflict detection More support needed – particularly for complex areas
6. Robustness checking (only mentioned when prompted)
Train Planners understand the need for this but consider it a ‘nice to have’ rather than a ‘need to have’. They consider that a skilled train planner can by ‘eye’ and experience tell whether a timetable will perform well or not.
7. Schedule generation/optimisation (only mentioned when prompted)
Train Planners are sceptical about the benefits of tools of this nature - an automated solution that does not completely solve the problem may be of no use at all - it may be easier to start again from scratch. It should be noted that, because the amount of manual intervention required is not known until the programme has run, optimisation does not help with planning workload and achievement of production timescales
6.5.2 Analysis
The above section provides a detailed list of objectives for software improvement that need to be considered alongside the broader objectives set out in the section in the last chapter on ‘compliance with train planning best practice’.
Supporting the views of train planners, it is essential that planners should have all the data they need to do their jobs in the systems that support them - they should not have to keep in their heads or on paper any of the information they need, most obviously the headway and junction margin data and similar that is essential to undertake the conflict resolution task. As far as possible the tasks should be automated and, where that is not possible for the time being, the tasks should be straight forward. All this is essential to make sure that the plans that result are consistent with the Rules of the Plan so that there is a reasonable chance that they are robust.
Reducing time pressures on train planners by eliminating rekeying and automating data preparation would appear to be a priority. The time freed up can be used in several ways. The most obvious use of this time is to improve the quality of the timetables and diagrams produced - this gives a short term gain. The more perceptive (and typically
more senior) train planners note, however, that this does not move forward the achievement of substantial efficiency improvements through the successful
implementation of sophisticated new software. Train planner involvement in software development is essential if the software is to be successful and, hence, some argued that the most appropriate way of using the time freed up by early improvements is to use it to support the development of requirements specifications and the testing of new software. In practice a mix of these two ways of using the time created would appear to be most appropriate.
Following on from this, tools must be provided which standardise train planning tasks and procedures and eliminate errors. This would give quality improvements and improves efficiency by reducing the amount of rework required.
Once these basic functions have been successfully addressed by the software, schedule generation/optimisation software that supports the development of more efficient
schedules can be developed. Not discussed by train planners, but the logical final step (to replace the iteration between process steps) is the development, eventually, of software that integrates timetabling, rolling stock diagramming and train crew diagramming, looking to optimise across these tasks.
The following table puts this analysis into a priority list.
Table 7: Summarised Priorities for Train Planning Software Development (Source: Author)
1. Tools that reduce production timescale pressures 2. Tools that promote best practice processes and support the production of error free outputs
3. Robustness checking software
4. Schedule generation/optimisation software that supports the development of more effective schedules
5. Software that integrates timetabling, rolling stock
diagramming and train crew diagramming, looking to optimise across these tasks
In the following two chapters, software is considered that seeks to address the first four of these priorities – firstly timetable generation software which covers the first, second and fourth and secondly simulation software which assesses timetable robustness (the
third priority).