An Access Rights Database and Validator N.G. Harris' & G.B. Cooper* the Railway Consultancy Ltd., London, UK. * Railtrack Pi

An access rights database and validator

N.G. Harris' & G.B. Cooper*

The Railway Consultancy Ltd., London, UK. * Railtrack pic., Euston Square, London, UK.

Abstract

Under European Commission regulations, railway infrastructure must either be run as a separate company independent of train operations, or have separate accounts prepared. In either case, however, formal access rights are required in order that it is clearly understood which trains are permitted to operate, where and when. In

Britain, there are over 30 operators with access rights onto Railtrack's network. Their legal rights are enshrined in Track Access Contracts, but there are a number of problems with these, which are making it difficult for Railtrack to manage the network, and to make investment decisions. Railtrack therefore conceived the idea of an Access Rights DataBase (ARDB), containing operators' rights in a

standardised numerical form; results from this will be presented. However, validating these access rights against existing timetables, and against operators' bids for future timetables, is a more complex task, for which a database solution was proposed and is being implemented. Railtrack's timetable Train Service

DataBase is being compared to the ARDB, but there are considerable difficulties in identifying trains in both databases. This paper sets out the logic used to overcome these problems, presents results from the practical solution being implemented, and sets out future developments for subsequent stages of this

project, which include: • an automatic link to the timetabling system; • development of a more standardised 'template' track access contract; & • reporting rights by location, as an aid to capacity management.

2Q4 Computers in Railways VII

1 Operating the privatised railway

Under European Commission regulation 91/440, railway infrastructure must either be run as a separate company independent of train operations, or have separate accounts prepared. In Britain, the railways were both fragmented and privatised by an Act of Parliament in 1994. Railtrack pic is responsible for the infrastructure whilst existing passenger services were put out to tender, with the lowest bidder winning the right to operate a franchise for a period of (typically seven) years.

Renegotiation of these franchises has recently started.

2 Track access contracts in Britain

In Britain, there are over 30 train operating companies (TOCs) with access rights onto Railtrack's network. These include franchised passenger operators, open- access passenger operators (such as Eurostar), London Underground, and freight operators. They need formal access rights, in order that it is clearly understood which trains are permitted to operate, where and when. Their legal rights of access onto the network are enshrined in Track Access Contracts, which are bulky documents containing details of the vehicles that may be used, the standard charges levied (and how these change if performance by either party varies significantly from that which was assumed) - and the accessright sthemselves .

The access rights are described in geographical terms - train operators need to know how many trains they are allowed to run over which parts of the network.

However, there are a number of'dimensions* of accessrights , including: • quantities of slots; • intervals between slots;

• slot journey times; and • connections between slots.

Even within these categories, rights can be expressed in a range of different ways. For instance, intervals between slots can be expressed as:

• number of trains per time-period (e.g. 1 train per hour); • maximum & minimum number of minutes between trains (trains shall be between 50 and 70 minutes apart);

• clockface intervals (trains must depart at the same time past each hour); or • as above but only on 5-minute points of the clock (xx:00, xx:05, etc.).

Unfortunately, the track access contracts were drawn up hastily and without any standard format. They have now been amended many times (for instance, as new services have been planned and introduced), and are becoming unwieldy for management information purposes. This makes it difficult to identify capacity sold,

Computers in Railways VII 205

and hence difficult for Railtrack to make investment and access sales decisions. It

may also be an obstacle to trading rights between operators.

Furthermore, it should be noted that the access rights are quite independent of the timetable. It is certainly possible for an operator to have more access rights than

trains in the timetable - operators can bid for slots but not take all of them up. However, the Rail Regulator can intervene in this process - if, for instance, it was felt that capacity was being purchased for the purpose of obstructing other operators, rather than for genuine use.

There have also been occasions when access rights have been found to be inadequate for the purposes of the timetable. A 'supplemental' agreement has therefore been required, in order to formalise the agreed rights. Some contracts

now have as many as 50 supplements, reflecting the dynamics of service change since privatisation.

3 A DataBase

Railtrack therefore conceived the idea of an Access Rights DataBase (ARDB), which would contain operators' rights in a standardised and more numerical form.

During 1998, agreement was reached as to which variables needed to be stored for the various types of access right. Railtrack pic then commissioned Sema pic to construct a database, in Oracle, with The Railway Consultancy Ltd being responsible for the population of that database. During 1999, the database was

constructed whilst the access rights of every train operator were coded up into Excel spreadsheets, which were themselves imported into the database. Between them, there were 37,000 access rights, covering the 20,000 daily trains on the British mainline railway network.

It was not necessary to code up all the accessrights , because some of them were either unusual and/or solely descriptive. Of the 119 logical types of rights found in a scoping exercise, there were 19 generic types. Of these, 12 were coded up within the database, but these cover over 90% of the total number of access rights. These

12 types are set out in Table 1, with the remaining seven types flagged for manual reporting by way of textual descriptions.

4 A logical hierarchy of access rights

For any train operator, access rights may be defined at one of a number of levels. At one extreme, there areright s which apply across an entire company's services -

there might be a cap on the total number of trains run per day, for instance. At the other extreme, many rights apply to train services with a particular stopping pattern - for instance, the TOC may be entitled to one of these per hour. In fact, we have had to generalise the notion of 'stopping pattern'. We have developed the

Computers in Railways VII concept of a 'location pattern', because we needed to include the details of freight trains which call at selected stations in order to change drivers, A Quanta - numbers of train slots B Trains per unit time - e.g. 1 train per hour C Maximum and Minimum Intervals between trains

D Maximum and Minimum Journey Times E Average Journey Times F Stopping Point Dwell Times (at stations, or for crew change or mail loading purposes)

G Clockface arrivals and departures (i.e. at the same number of minutes past each hour) H Number of Station Calls (i.e. up to x trains per day may call at a station) I Point on Clock (i.e. confining a slot to be at xx:00, xx:05, etc.)

J Total Station Calls for Service Group (i.e. up to y trains per day may call at a group of stations) K Particular (e.g. first, last) Services (e.g. the first train of the day may call additionally at station X)

L Pseudo Quanta - totals of train slots, descriptions of 'white' periods during which no trains may run

Table 1. Types of Access Rights Coded

and also because some data relates to routeing choices when a train does not actually call at a particular station.

However, location patterns are very specific. For each pattern, the TIPLOC code for every relevant station or junction is noted, together with a further column of data called the PSPB indicator. This sets out whether the train is only allowed to Pass that location without stopping, or whether it is permitted to Set down passengers, Pick up passengers, or do Both.

Location patterns are normally part of a service code, which are defined by route. They comprise a range of similar services on the same line whose location patterns may vary solely because of minor differences in which trains stop at which stations. However, the system also needs to be able to deal with access rights which are grouped across routes e.g. at a terminus station, there may be a cap on the total number of trains permitted across all the relevant service codes. The database therefore uses the concept of 'Service Code Group' to analyse such examples. The inter-relationships between the different concepts used within the database are set out in Figure 1.

The database functions through a series of lookup tables. Service Codes are comprised of Location Patterns, Service Code Groups and Routes are both comprised of Service Codes, whilst Routes are joined together within Train Operating Companies. Each of these relationships is defined by two tables within

Computers in Railways 177 207

the database, one a summary including names, and the other a detailed lookup

table.

Initially, it was a large task to define all these relationships for each TOC, as well

as entering all the data. However, this stage of the project was completed during 1999 in respect of the access rights current for the Winter 1998-1999 timetable. Results from thatfirs tstag e of the work have enabled Railtrack managers to find, understand and use information on access rights much more easily. For instance,

the database was available to support the 1999 timetabling conference.

5 Validation

However, as we have noted, it is possible for the timetable and access rights to differ. It was therefore desired to validate the access rights against existing timetables, and against operators' bids for future timetables. This is a more

complex task, for which a more sophisticated database solution was proposed and is being implemented. Railtrack's timetable Train Service DataBase is being compared to the Access Rights DataBase, but there are considerable difficulties in identifying trains in both databases, for reasons including:

• access rights are defined in different dimensions (e.g. number of trains, journey times, intervals) • trains may satisfy more than one access right; and

• access rights may also be defined of groups of trains. The implication of the last two points is that relationships are both one-to-many and many-to-one.

This stage of work has required a larger computing solution, which is being carried out by Sema pic, working to instructions from Railtrack who hold the IPR The ARDB and TSDB datasets are respectively 80 and 120 Mb, whilst the program has grown to take up a further 10Mb of space. However, with modern pc

computing power, these are not impossible dimensions and so, as part of the project, additional pcs have been provided for each of the commercial teams working in Railtrack's seven zones. The Oracle computing environment chosen enables users in the Railtrack zones to access this data whilst security is maintained by only allowing editing at Railtrack headquarters. The zones are,

however, allowed to create scenarios in order to ask "What if?" questions.

The current status of work is that access rights have now been updated to the 2000 timetable, through a process of validation which occurred through the Spring

and Summer of 2000. Computer checks revealed discrepancies between the two databases which needed to be sorted out. This process has resulted in some access agreements being reworded for increased clarity, in negotiations about changes to the level of track access charges, and in errors being removed from both the TSDB and the ARDB.

4 Route e.g. Dartford lines

Orpington lines Kent Coast

9 Service Code Group (often location-, rather than TOC-specific) e.g. all trains across 1 Train Operating Company Rochester Bridge, e.g. South East Trains all trains leaving Char X

7 Location Pattern Service Code

(=Stopping Pattern) e.g. Dartford via Sidcup e.g. CX - Sid - Dart slow Dartford via Bexleyheath CX - Sid - Dartford fast Dartford via Woolwich Can St - Sidcup

TDPLOCs (station codes)

1 List of Train Operating Companies 4 ARC_TOC_ROUTE_DEF defines route code e.g. 21 CX/Can St - Dartford via all routes

5 ARC_ROUTE_REF lists TEPLOCS on that route, in order 6 ARC_SERVICE CODE gives services within route code e.g. 110, 112 within 21 7 ARC_LOCATION_DESC summarises stopping patterns e.g. 2500-

2800 in route 21 8 ARC_LOCATION PATTERN describes stopping patterns of route 21 9 ARC_SERVICE_CODE_GROUP defines service code group 10 ARC_GROUP_CODE relates services code (110,112) to service code

Figure 1. Hierarchy of Stopping Patterns and Service Groups

Computers in Railways VII 2f)Q

The validator functionality has been specified and is the software is now being written and tested. The fully-populated database and validator is expected to be available by August, ready to assist Railtrack to respond to the access rights changes expected to arise from the re-franchising process.

6 Future developments

Future developments for subsequent stages of this project include: • an automatic link to the timetabling system, which would generate timetables from theright swhic h operators have;

+ development of a more standardised 'template' track access contract; and • reporting rights by location, as an aid to capacity management. These are considered in turn below.

6.1 Automatic link to timetabling

At present, timetables are constructed to meet commercial and contractual constraints which are recorded on paper and/or imperfectly remembered by the timetable planner. Once written, the timetable can then be tested using the ARDB against a computer-generated record of access rights.

A better method would be to feed the computer record of the accessright sdirectl y into an automated timetabling process, which would treat that record as a design specification. The advent of PTG (Planning Timetable Generator) is beginning to allow this possibility (Cooper, Watson and Grant [1]). The automatic link between the two systems is currently being developed on this basis.

6.2 Template track access contracts

It would also have saved considerable time, both during the initial franchise letting, and subsequently, if a standard or 'template' track access contract had been available. This would have reduced unnecessary differences, and helped to ensure that some unhelpful rule types and descriptions were avoided.

Subsequently, it has been possible to develop best practice, in terms of clauses which are legally watertight, and logically unambiguous. There is a balance, however, between avoiding unduly prescriptive access rights (which merely act as a duplication of the timetable) and being so vague that the meaning is not clear, or where alternative slots (which might be unacceptable to Railtrack) might be legally permitted.

The template is now available electronically, enabling the agreements for new operators, or new clauses for existing operators, to be dealt with much more efficiently.

6.3 Rights by location

At present, the access rights are defined by TIPLOCs. These are a seven-character

alphabetic code relating to stations or junctions as appropriate. However, with 16650km of route in Britain and 7000 TIPLOCs, this means that a full understanding of the access rights requires a very comprehensive and detailed knowledge of the railway network. Linking the rights to a Geographic Information

System would enable rights to be shown geographically on the screen of a pc, rather than in coded format.

Moreover, a knowledge of the slots sold does not directly help in assessing how

much capacity is unsold - a key question for an infrastructure company such as Railtrack. It is therefore intended to read in additional information about the capacity of each section of route, in terms of trains per hour.

The final stage of the project is intended to bring these two enhancements

together. It should be possible to enter two place-names, and for the route between these to be displayed on the screen. This will be accompanied by a table showing the number of slots sold and remaining. This will have to be split down by time-period, certainly at the level of peak:offpeak, and probably by hour. Only

then will it be possible to see at a glance what the real usage of the Railtrack network is, and for the investment process to be taken forward smoothly to cater for the growing demands upon that network.

7 Conclusions

When infrastructure is formally separated from train operations, proper legal

contracts are required in order that the access rights of any operator are clear. For a network of any size, this generates a considerable quantity of complex information. Such data is most easily managed within a database environment, provided that a standardised form of contract is adopted.

This paper has described the steps that Railtrack has taken in the UK to develop a database which enables it to manage its access rights efficiently. This was enabled by the analysis of the essential logic of such rights. The resulting data structure and programs then sped up the process of responding to requests for service

changes, and enables Railtrack to understand capacity issues and investment requirements, not just on the basis of the current timetable, but also to reflect future planned sales.

References

[1] Cooper, G B, Watson & Grant, B (2000) Public Transport Scheduling conference, Berlin, June.