Data Format and Exchange Interface Clause Samples
Data Format and Exchange Interface. Static information is shared in the RECIFE data format. It is an xml representation compatible with railML. It is based on three sets of data: infrastructure, timetable and rolling stock. The former includes all microscopic information on tracks. Namely, it reports all details on track detection sections, block sections, signals, stopping points and possible journeys. Journeys are sequences of block sections that can be traversed by trains. As a further specification of journeys, journey instances are possible ways to travel along a journey: depending on the used rolling-stock and stopping pattern, journey instances include information on run- ning and clearing times on each track detection section, as well as sequences of track detection sections that are occupied by a train simultaneously, depending on the train length. The set of data on timetable includes the types and list of courses (services) that need to be performed in a day, or any time horizon. For each of them, information supplied includes the type of rolling stock, the planned entry and exit time from the infrastructure, the planned arrival and departure times at stops, and the set of journey instances that can be used to perform the course. In the timetable, planned rolling-stock re-utilizations and passenger con- nections are also detailed. Finally, the set of data on rolling-stock reports all in- formation necessary to compute train motion equations, as well as data as train lengths. A detailed description of the static data format is available at ▇▇▇▇://▇▇- ▇▇▇▇.▇▇▇▇-▇▇▇▇▇▇.▇▇/▇▇▇▇▇▇▇▇▇▇/▇▇▇▇_▇▇▇▇▇▇_▇▇▇▇▇▇▇▇▇▇▇▇▇/ . Dynamic information is shared following the data formats defined within the ON- TIME project and detailed in Quaglietta et al. (2016). This format follows an xml representation as for dynamic data. It includes two main sets of data. On the one hand, the traffic state prediction details train trips. An example is reported in Figure 10. Here, two trains (T1 and T2) are in the infrastructure con- sidered. For each of them, the data indicate the track detection section in which the train is at the considered time and at which time the train accessed it. For trains which are expected to enter the considered infrastructure in the near future (T3 in the example), the expected entrance time is reported. This data format can be used to describe both the current traffic state or a predicted one. The predicted traffic state is the one on which decision making is based: as a few minutes a...
Data Format and Exchange Interface. The pre-day simulator module receives data in the CSV format (Table 9). The new network skim matrices for rail, generated by the EGTrain simulation, must update the original skim matrix document with revised information on: rail in- vehicle travel time in hours between two zones, rail access/egress walking time in hours between two zones, rail waiting time in hour between two zones, rail costs of travels between two zones, average number of rail transfers for travelers between two zones and rail out of vehicle travel time in hours between two zones. This list may be extended later within the SortedMobility project to include level- of-service measures of interest to the self-organizing system (e.g.: reliability measures).
Data Format and Exchange Interface. The online demand prediction module uses data in the standard format General Transit Feed Specification (GTFS). In general, a GTFS feed is a collection of sev- eral CSV files. In this report, we limit the description to the files used in the online demand prediction module and its interaction with the traffic control module. For more information about the GTFS, see ▇▇▇▇▇://▇▇▇▇.▇▇▇. The GTFS files used in the online demand prediction module are called: routes, stops, trips, and stop_times. The files trips and stop_times are dynamic docu- ments provided by the traffic control module. The file trips includes the list of all train courses (trip_id), each with the assigned route (route_id). The file stop_times, instead, corresponds to an extract of the RTTP which includes for each train course: the planned time of arrival at given stop (arrival_time); planned time of departure from given stop (departure_time); unique id of the stopping location (stop_id), i.e., station or platform chosen; position of stop in sequence (stop_sequence) tied to the course id. The static documents routes and stops include, respectively, the list of routes (sequences of portions of journey instances, using the wording of Section 4.1.1) and stops within the transport system considered. These documents are used in combination to the dynamic ones in the online demand prediction module to ex- trapolate and define available run-paths for passengers related to lines (routes) as well as transfers. Therefore, the demand prediction module provides to the traffic control module the Passenger Assignment Plan (PAP) in an xml representation compatible with RECIFE data format. The PAP includes the list of homogeneous groups of ▇▇▇▇▇▇- ▇▇▇▇ and the following details for each group: origin and destination station, num- ber of passengers in the group, departure time from the origin, arrival time to destination, reference and alternative passenger journey instances (run-paths). A passenger journey instance is a sequence of courses (train services) that can be used by a passenger group to travel from origin to destination at the desired time. For each passenger journey instance, the PAP details the first and last train and the list of intermediate passenger-connections. Each passenger-connection includes the following information: name of the arriving train and departing train; name of the station where the trains are connected; minimum transfer time and maximum tolerance time, i.e., how long the depa...
Data Format and Exchange Interface. The data exchange is based on an XML formalisation that has been developed for representing the current traffic state and the RTTPS in the ON-TIME project (Qua- glietta et al. 2016). A dedicated API will be created for the calling of the route- coice function within EGTrain.