TNV-Prepare: Analysis of Dutch railway operations based on train detection data

TNV-Prepare: Analysis of Dutch railway operations based on train detection data Goverde, R.M.P., Hansen, LA. Faculty of Civil Engineering and Geosciences, Delft University of Technology, The Netherlands Abstract TNV-Prepare is a tool that derives detailed information of event times associated to train services from data records of the Dutch train describer systems, the socalled TNV-systems. The data records contain signalling and interlocking information of an entire traffic control area. The TNV-Prepare output consists of TNV-tables per train line service and (sub)route. For each individual train event times (with a precision of a second) along the route are given, including train description steps, section entries and clearances, signals, and point switches. The TNV-tables give excellent analysis opportunities of railway operations that have not been possible before. 1 Introduction The availability of reliable and accurate data of railway operations gives important opportunities in the railway planning process. It can be used for evaluating timetable performance, providing insight in the stochastic processes of railway operations, evaluating station capacity, detecting bottlenecks, and validating and calibrating railway simulation models. At the Delft University of Technology the need for accurate data of railway operations arose to evaluate developed methodologies on robust railway timetable design, station capacity estimation, and operational control strategies. The demand for accurate data was also recognized by several Dutch railway companies, including Railned, NS Verkeersleiding, NS Railinfrabeheer, and Holland Railconsult. Existing data collection methods used by NS Verkeersleiding and the railway customer organization ROVER only give rough estimates in minutes of

7 g() Computers in Railways VII arrival and departure times. These figures give some indication about punctuality but lack the precision, accuracy, and detail for research purposes [1]. However, the desired data was recorded by the train describer systems in a most elementary form, although these records were only kept for a few days - to support the investigation of incidents - and then deleted [2]. Therefore, the TNV-Prepare tool has been developed for deriving data from these rough train describer records. 2 TNV-systems A train describer is a system that identifies a train at a particular position and keeps track of its progress from berth to berth. In the Netherlands, the train describer is implemented as the so-called TNV-system (TNV stands for the Dutch abbreviation of 'train number following'). A train description (or train number) is a unique number (per day) identifying the train line service (characterizing the train type, terminal stations, route, and served stations) and including a discriminating counter for successive trains. The location of a train number is based on TNV-positions. A TNV-position consists of one or (usually) more adjacent track sections between two (not necessarily adjacent) signals. A train number is inserted into a TNV-system, either manually or automatically (e.g. at line ends), at the TNV-position of the platform from where the train starts its journey. The movement of a train is detected by signal controls, point detection, and track circuits, and this information is sent to the TNV-system. The route that is set behind the signal that the train is approaching determines the next TNV-position. A TNV-step of the train number to the next TNV-position is triggered when the train enters the first associated track section. So, the TNVposition of a train corresponds with the track circuit occupancy but moves in larger steps. More details about train describers can be found in Bailey [3]. The Dutch railway network has been divided into 16 traffic control areas, each having a separate TNV-system. If a train approaches an adjacent traffic control area, its number is transmitted to the associated TNV-system. When the train enters the next traffic control area the train number is cleared from the present TNV-system and inserted into the next. A main module of a TNV-system is data collection referring to the scanning and recording of inputs. The TNV-system must be continuously aware of the state of all relevant signalling controls and monitoring information, including the attached track, signal, point, and route relays. Therefore it receives information from the interlocking systems (B-relays, VPI), signalling control systems (EBP), and/or combined interlocking/signalling control systems (BBS). Moreover, it must take notice of manual instructions from operators and messages from other TNV-systems. A second main module is data manipulation corresponding to inserting and clearing train numbers, determining TNV-steps, and keeping track of the TNV-positions of all train numbers in the system. The third basic module is transmitting the TNV-positions of train numbers to process supervision systems (PSS), train traffic control systems (TTCS), and passenger information systems (Bepac). Figure 1 shows the data flows between a TNV-system and its

Computers in Railways 111 781 traffic control TTCS passenger info Bepac signal control EBP, BBS interlocking relays,vpi, BBS train detection / railway infrastructure track circuits, points, signals Figure 1 Data flows to and from a TNV-system environment. For more details about the Dutch railway system architecture, see Brok & Vissers [4], Renkema & Vas Visser [5], and Fries & Sprakelaar [6]. A TNV-system keeps a real-time record of received inputs and TNV-steps. These TNV-logfiles are extremely large (about 25 MB ASCII-format per day) and inaccessible since they contain chronological information about all signalling and interlocking events in an entire traffic control area. However, the files clearly contain valuable realization data of the railway operations. Therefore, the TNV-Prepare application has been developed to convert the TNVlogfiles into detailed data suitable for data analysis. 3 TNV-Prepare TNV-Prepare converts TNV-logfiles into tables of successive events on a route of a train line, including TNV-steps, section entries, section clearances, signals, and point switches. In the sequel these tables are called TNV-tables. TNV- Prepare runs on MS Windows 95 and NT operating systems. Within TNV-Prepare, the rail infrastructure is implemented as a set of coupled and connected objects (infra elements). An object can either be a section, TNV-position, point, or signal. The basic objects are the sections. Each section may have up to two successor sections corresponding to a boundary section of the selected area (zero successors), a track section (one successor) and a point (two successors). Moreover, a section may have additional attached objects. A TNV-position is attached to its last section. A point is attached to a section with two successors. The columns of TNV-tables correspond to the successive sections on the route including the attached objects. An exception is a TNV-position, which is located at itsfirstsection, conform the occurrence time of a TNV-step (whereas

782 Computers in Railways VII the TNV-position itself is determined by the last section of a set route). Each object on the route has one or more associated events/columns, see Table 1. For a section occupied by the current train three event times are reported: the section entrance time, the next clearance time, and also the previous clearance time. Note that the previous clearance time usually relates to a different train but is interesting for capacity analysis. Likewise, three events are reported for a signal as well: the stop and proceed signal caused by the current train, and the previous proceed signal. Object TNV-position section signal point Table 1 Objects and associated events Events TNV-step last clearance entrance next clearance last proceed stop next proceed last left switch last right switch TNV-Prenare input train lines timetable & route (interactive) J \ feasibility check routes internal database Figure 2 Architecture of TNV-Prepare

Computers in Railways VII The TNV-Prepare application consists of three main modules as depicted in Figure 2: TNV-Prepare: builds an internal database from TNV-logfiles and additional inputs; TNV-Report: generates TNV-tables; TNV-View: displays TNV-tables and exports tables to external formats. The next sections present the three modules in more detail. 3.1 The TNV-Prepare module The first main function of the TNV-Prepare tool is to prepare an internal database from which TNV-tables can be composed. It is the core of the tool and hence is also called TNV-Prepare. The module initially requires interaction with the user to fix the basic information data set of the traffic area. Once this information has been stored in the database, TNV-tables can automatically be composed from imported TNV-logfiles, including future TNV-logfiles provided that the used infrastructure, routes, or timetable have not been changed. The TNV-Prepare module contains several functionalities as indicated in Figure 2. First, the import utility reads TNV-logfiles, rejects excessive information, and stores the remaining data in an internal format optimized for search facilities. Second, the rail infrastructure has to be defined. The first and last TNVposition of a train line is interactively chosen, see Figure 3. If a route between the TNV-positions has not yet been defined a session starts to determine the associated objects and their topological relationship. Only rail infrastructure has 783 13:30:35 103 EHV$210 13:30:36 103 EHVS210T 13:30:36 103 EHVS117BT 13:30:42 103 EHVS193BT 13:30:43 103 EHV5278 13:30:45 103 EHVS131B 13:30:45 103 EHVS131A 13:30:45 103 EHVdOlB 13:30:45 103 EHVflOlA 13:30:45 103 EHV4125T 13:30:48 103 EHVS108BT 13:30:49 103 EHVU48 13:30:53 103 EHVS256 13:30:54 103 EHVg255T 13:31:00 103 EHVS257AT 13:31:03 103 EHV(210T 13:31:04 103 EHVS261BT 13:31:08 103 EHV5256AT 13:31:09 103 EHVS256BT T leindhovcncs STOP BEZET Figure 3 TNV-Prepare window to select range of TNV-positions (highlighted) of a train line service

784 Computers in Railways VII to be defined for train lines of the user's interest. The rail infrastructure will become more complete with each addition of a train line and route. Additional objects (points and signals) can separately be attached to a section using the object editing utility. Subsequently, the user is asked to add data relating to the timetable, including the route(s), frequency, and the planned arrival time, departure time, and platform track section at a particular station. Standard routes are defined using the route editing utility, and can be defined in terms of predefined subroutes which relieves the manual input session. A defined route is checked on feasibility with respect to the rail infrastructure, i.e., it has to be a sequence of connected sections. The TNV-Prepare module also contains utilities to edit or add objects, and to view and edit timetable information. These functionalities can be used to adjust incorrect input or to reflect onto changes in the infrastructure or timetable. 3.2 The TNV-Report module The TNV-Report module composes TNV-tables based on the data collected by the TNV-Prepare module. The user fills in the desired train line and period and the module generates the associated TNV-tables, see Figure 4. Also several train lines and/or periods can be given before starting the generation of the TNVtables. This is convenient as the generation of a TNV-table may take a few minutes to a few hours depending on the PC-speed, the required period (from a day to several years) and route length (a local route within a station vs. a route over the entire traffic control area covering many stations). Furthermore, after the generation has been started intervention of the user is no longer required. Jokafe EHV gorier* F^o" fieriode, 21 ^! flnwchrijving, IC line 1500 in direction Heerlen at Eindhoven CS - autumn 1999 ' {Eindhoven CS Figure 4 Input window of TNV-Report TNV-Report searches in the database for the first TNV-step of the selected train line. It checks whether the route corresponds to a predefined standard route for the specific train line. If a deviation of a standard route is found the train number is stored as unsolved. Otherwise, a new row is created in the relevant TNV-table and filled with the event times associated to the various objects. Inconsistent data is rejected resulting in empty cells at the particular columns in the TNV-tables. Also lacking data is detected and give empty cells. The rows in

Computers in Railways Vll a TNV-table are thus guaranteed to be consistent. If the train path of a train number has been completed TNV-Report looks for the next train number. To increase the computation speed a restricted search time period is used for finding the event times associated to objects along the route. For instance, a point on the route may not have been switched for hours and the exact switching time is then of no interest for the current train. The search period per train number can be set between zero and ten minutes before thefirstand after the last TNV-step of a row. If an event has not been logged within this time period then the associated column in the TNV-table is left empty. TNV-Report terminates when the end of the required period is reached. The results can be displayed by TNV-View. If there are still unsolved trains (that took an unknown route) this is reported in a logfile attached to the TNV-table(s). If necessary the routes of the unsolved trains can be traced and added to the database using the TNV-Prepare module (see Figure 3). 3.3 The TNV-View module The TNV-View module displays the generated TNV-tables. Each row of a TNVtable corresponds to a train number at a particular day. The first four columns contain the date, train number, scheduled arrival time, and scheduled departure time. The next columns give the event times associated to consecutive elements on the train path. Figure 5 shows a part of a TNV-table as displayed by TNV- View. The successive columns correspond to a signal (first three columns), a TNV-step (fourth column), a section (next three columns), a point (next two columns), and thefirsttwo columns of the next section. Note that the empty cells in the columns associated to point 255 imply that the point has not been switched for over 20 minutes, which is the search period up to entering the associated section 255T (see Section 3.2). Equivalently, an empty cell in the clearance columns (columns 5 and 10) denotes that the associated section has been cleared for over 20 minutes before the current occupation. TNV-View has several viewing options. The heading row and thefirstfour [TNV label : T 00283001 785 08:24:05 1 08:34:31 08:35:45 : 08:34:31 09:30:05 09:32:44! 09: 35:1 4 =09:32:44 10:23:30 10:36:51 ; 10:38:35 '10:3651 11:29:21 11:32:35 11:37:23 J1 1:32:35 12:28:04 12:31:33, 12:34:05 12:31:33 13:28:04 13:30:39 113:35:28 i 13:30:39 14:32:11 Jj, 14:34:59 ll 4:38: 34 i 14:34:59 08:34:31 08:34:53 09:18:01 09:32:44 09:32:59 10:36:51 10:37:11 11:16:44 11:32:35 11:32:58 12:17:02 12:31:33 12:31:52 13:16:35 13:30:39 13:30:55 : 14:30:19 14:34:59 12:17:10 131642 14:35:15 14:26:00 14:32:05 14:30:02 08:34:39 09:18:09 09:32:50 10:36:59 11:16:52 11:32:44 12:31:40 13:30:46 14:35:06 Figure 5 Part of a TNV-table displayed in TNV-View

786 Computers in Railways VII columns can be frozen when scrolling through the data cells. Several windows containing different TNV-tables can be viewed simultaneously. Moreover, these windows can be coupled and jointly scrolled to facilitate comparison of related TNV-tables. Furthermore, columns can be automatically hidden to focus on particular events. For instance, hiding all columns except section entries gives a view of the progress of a train over a route. Another functionality of TNV-View is the export utility. TNV-tables can be exported to common spreadsheet formats like tab-delimited and commaseparated. Hidden columns may also be excluded in these exported files. Any spreadsheet and statistical software program can read the exported files. 4 Data accuracy and reliability The event times in the TNV-logfiles correspond to the time instants at which the events are logged by the TNV-system. This logged event time may differ from the actual event time as a result of transmission delays or noise. However, a transmission delay is usually only a fraction of a second, and also the time necessary to log a received message is negligible. Note that event times are given in seconds and so the precision is at least a second. Confirmation of the accuracy and reliability of the (logged) event times can be obtained by tests based on route logic. First, synchronous events should have equal occurrence times. A triple of synchronous events occurs at the first section of a TNV-position that is located near a signal. Figure 5 shows this situation: section 255T after signal 256 is the first section of TNV-position EB1/EB1S.O. The occurrence of a stop sign (column 2) is synchronous with the section entrance (column 6) and the TNVstep (column 4). This implies that the logging of a received message from the signalling system occurred in the same second as the logging of the TNV-step, which has been computed by the TNV-system based on the received section entrance. This synchronicity has been monitored at all data of Eindhoven. It can be concluded that the computation time of a TNV-step is negligible, and the same holds for the recording time of an event. Moreover, it can be concluded that the transmission of messages from the signalling systems is noise-free. A second test is based on the chronological ordering of events. For instance, successive sections of a route must be occupied consecutively (compare the sixth and last column in Figure 5), also a section can only be cleared after the entrance of an adjacent section (compare the seventh and last column in Figure 5). These route logic based tests are performed by TNV-Report, which detects and discards inconsistent data, resulting in empty cells in the TNV-tables. Thus, the generated TNV-tables only contain consistent data with respect to the route logic. Note that the last section clearance before the entrance of the current train usually corresponds to different trains. So the last clearances of successive sections may be caused by a train running in the opposite direction (compare the 5th and 1 Oth column of the last row in Figure 5) or by a crossing train route. These events should therefore not be compared with the route logic of the current train.

Computers in Railways VII Empty cells may also be the result of missing data. TNV-Prepare detects missing events by logical rules. As an example, suppose that a TNV-step has been logged but a section of the previous TNV-position has not yet been occupied. Clearly, the train has passed the section but for some reason this has not been detected, transmitted, or recorded. The missing event results in one or more empty cells in the TNV-table. An event is only registered in a TNV-table if a logical test guarantees its consistency. Analysis of the generated TNV-tables at Eindhoven show that the number of empty cells caused by inconsistent data is negligible, even at periods of heavy (communication) traffic. It can be concluded that the logged event times equal the actual event times with an error smaller than one second and the TNV-tables generated by TNV-Prepare/Report thus accurately represent the actual traffic processes. 5 Data analysis opportunities The TNV-tables allow a variety of opportunities to analyse railway operations including capacity analysis, punctuality analysis, and assessment of stochastic railway processes. The actual arrival and departure times at the platform are not registered and hence neither given in a TNV-table. However, the exact time that a train enters the platform track section is known, and from here the remaining running time to standstill is only small and can be estimated accurately. The speed profile of the train approaching the platform can be estimated from the previous section entrance times and the known section lengths. Furthermore, if the stop location at the platform depends on the train length then this can also be estimated. The estimated train length is the product of the estimated speed at a section border and the necessary time to pass this section border (the elapsed time from an entrance time to the next clearance time of the previous section). In the same way the actual departure times can be estimated as the entrance time of the first section after the platform section subtracted by a computed acceleration time from the platform. From the above follows that also the actual arrival and departure times at a platform can be computed accurately. Therefore, also empirical probability distributions can be derived for arrival and departure times of a train line at a platform, the dwell times at a platform, and the running times between stations. An illustration of a detailed analysis based on TNV-tables is the following. The first six rows of Figure 5 show a regular behaviour for successive trains. The route has here been cleared for over 14 minutes (cf. columns 5 and 6, and 10 and 11). The last row however shows an irregularity. A train has passed point 255 (and sections 257AT and 255T) from the opposite direction. After the point has been reset in its original position it takes another 7 seconds before the route has been set and locked and signal 256 is cleared. Then it still takes another 2 minutes before the current train enters section 255T. This kind of detailed information is valuable for capacity analysis and analysis of process control measures.

"7QQ Computers in Railways VII, C.A. Brebbia J.Allan, R.J. Hill, G. Sciutto & S. Sone (Editors) Computers in Railways VII 6 Conclusions TNV-systems keep a real-time record of train description steps and received events from the safety and signalling systems (BBS, EBP, VPI, B-relays), with the precision of a second. Based on these TNV-logfiles, the TNV-Prepare tool generates TNV-tables suitable for data analysis. A TNV-table corresponds to a subroute of a single train line within a traffic control area. The tables consist of the occurrence times of successive events on a train path (columns), for each individual train of the line (rows) during the analysis period. Alternative routes of trains on a line are given in separate TNV-tables. The first experiences with TNV-Prepare are very promising. The TNVtables reliably and accurately represent the actual railway traffic processes. However, if the tool will be used generally throughout the Dutch railway network, manual input of the initial rail infrastructure will be too laborious. Instead, the TNV-Prepare system should then be linked to CARE which also provides the configuration data of the TNV-systems, see Fries & Sprakelaar [6]. Current research includes an extensive statistical analysis of railway operations based on generated TNV-tables of Eindhoven CS, The Hague HS, Rotterdam CS, and the corridor between Rotterdam CS and The Hague HS. These TNV-tables correspond to TNV-logfiles collected during one week in 1997 in the area Eindhoven, and during September 1999 in the area Rotterdam and The Hague. The results will be reported in future papers. Acknowledgement - This publication is a result of the research programme Seamless Multimodal Mobility, carried out within the TRAIL Research School for Transport, Infrastructure and Logistics, and financed by Delft University of Technology. References [1] Goverde, R.M.P., "Analyse van treinpaden in stations m.b.v. TNV- Prepare", Proceedings Workshop modellen voor de beheersing van treinverkeer, TRAIL Research School, Delft, 1999 (in Dutch). [2] Damen, A., Uitvoeringstijden treinactiviteiten in Vervoersgegevensbank VKL, internal document, NS Verkeersleiding, 1997 (in Dutch). [3] Bailey, C. (ed.), European Railway Signalling, Institution of Railway Signal Engineers (IRSE), A&C Black, London, pp. 311-342, 1995. [4] Brok, M. den, Vissers, R., "VPT, a new systems architecture for planning and control of train traffic in The Netherlands", in: T.K.S. Murthy et al (eds.), Computer in Railways IV, Vol. 2, CMP, Southampton, pp. 19-26, 1994. [5] Renkema, M., Vas Visser, H., "TRACE supervision system for dispatching and passenger information", in: J. Allan et al. (eds.), Computer in Railways V, Vol. 2, CMP, Southampton, pp. 247-256, 1996. [6] Fries, G.A., Sprakelaar, J. van, "Computer aided railway engineering", in: B. Mellitt et al. (eds.), Computer in Railways VI, CMP/WIT Press, Southampton, pp. 53-59, 1998.