servers with access to delay information (e.g. delayed ICE 721 in Figure 11.1). Addi-tionally, the connection status is verified in such a server and displayed in the bottom line.
For the connection in Figure11.1we see the departure and arrival times according to the schedule and, for the delayed ICE 721, the updated event times. Without the delay, an earlier connecting train would have been reached at Frankfurt main station.
In Figure11.2we see the comparison display for an on-trip search. Assume a passenger is at station Hamburg at 5:00 in the morning (maybe he missed a connecting train). He queries MOTIS for a connection to W¨urzburg. The two selected servers are MOTIS with (blue #1) and without delay information (yellow #2). Connections are marked according to the server that found them. The first and second were found by server #1 and #2, respectively. The last two were found by both servers. Note that server #1 added delay information to the results one, three, and four. The connection that reaches W¨urzburg first was determined by server #1. It arrives 25 minutes earlier than the connection from server #2. The last two connections have less interchanges, the last is cheaper. Therefore, these alternatives are shown. Note that the travel time is counted starting at 5:00. The first and best connection has an initial waiting time of 20 minutes before it departs at 5:20 (bottom figure). The interchange in Kassel-Wilhelmsh¨ohe is only possible due to the delay of the connecting ICE 531. A server without delay information would not have been able to find this connection.
When introducing reliability of interchanges in Section 6.3, we saw a multi-server display in Figure 6.1, comparing two servers with and without reliability of interchanges as an optimization criterion. The scores for reliability of a single interchange or the whole connection are symbolized by intuitively understandable graphics, here clocks for interchanges (cf. Figures6.2and11.1) and stars in Figure6.1, (the more the better).
11.3 Connection Controller and Alternatives System
We implemented a proactive route guidance system, that constantly checks the status of travel plans, offering information about status changes and supporting the search for al-ternatives, calledConnectionController andAlternativesSystem (CoCoAS). This system offers a new service to the public and demonstrates the benefits provided by a system with delay information as introduced in Chapter7.
The system basically works as follows: A user can register a planned trip obtained from any timetable information system for controlling. Starting some time before the actual departure of the connection, the connection is continuously checked for status changes. Recall from Chapter7the potential states of a connection:
• Journeys can either be still valid (i.e., they can be executed as planned),
• they can be affected such that the arrival at the destination is delayed, or
• they may no longer be possible.
Whenever a status change occurs (or some predetermined change within a certain status, e.g. a significant increase or decrease of the delay time in the second case), or only when the status changes to “broken” and an action is required, the system informs the customer about it via SMS or e-mail.
Figure 11.2: An on-trip query from Hamburg main station (Hbf) to W¨urzburg main station (Hbf). The comparison display (top) shows connections determined by on-trip search with (blue) and without (yellow) delay information. Details for the fastest con-nection (bottom).
Now the customer may log on to our web site (per notebook or smart-phone) and inspect his connection, the current delay, and how endangered the interchanges are. If the interchange takes place one hour in the future and we have 1 minute less than the required interchange time, we may still have hope. On the other hand, a forecast arrival after the departure of the connecting train should most certainly trigger the search for an alternative.
In case alternatives are requested, the system determines the current position of the customer, either in a train or waiting at a station. More precisely the current position should actually mean the position at the time the passenger is ready to travel. Customers may specify the time needed before being able to change trains. More preparation time might be required when traveling with luggage or children, than when only carrying a newspaper. In case a train change is planned at the station anyway or the passenger is already standing at a platform, this time is zero.
With this position the corresponding type of on-trip query is executed. The
on-11.3 Connection Controller and Alternatives System 183 trip queries guarantee to only deliver valid alternatives. Instead of querying a system at a station after already missing the connecting train, this type of system allows the alternatives to be determined while there are still many more possibilities. The following types of alternatives may be presented:
• Different change. Change at a station originally planned for changing trains but to another train.
• Earlier change. Change trains before arriving at a station originally planned for changing trains.
• Later change. Stay longer in the train and change at a station after one originally planned for changing trains.
• Different start. Sometimes problems with a connection are known before the pas-senger has boarded the first train. In such cases, alternatives that require taking a different first train, maybe even some minutes earlier to reach the destination in time, can be produced by our system. Our system requires the earliest time a user could arrive at the station and the time needed from notification to reaching the station to provide such alternatives as well.
Note that the planned interchange mentioned above does not need to be the broken in-terchange, it may be any interchange not after the broken one. The calculated alternative is then merged with the original connection up to the starting point of the alternative,
Figure 11.3: CoCoAS example: Connection status at 10:50 - broken. 6 minutes are missing to complete the interchange in D¨usseldorf.
Figure 11.4: CoCoAS example: Overview of the alternatives for the broken connection
resulting in an alternative from source to destination. Even in the case ofdifferent change the system can produce better connections than any system without delay information.
The other cases are not supported by any commercial system right now.
After selection of the best alternative, this becomes the connection currently super-vised and the customer receives status message for this connection from now on.
Incidentally, our system may not only reduce the delay at the final station, it may also allow passengers to arrive earlier, in case an interchange arises due to a delayed connecting train. If a train is delayed by 10 minutes, changing to this train may become feasible. So instead of taking the next train of that route scheduled to leave 50 minutes later (a periodicity of one hour assumed), changing to the delayed train greatly reduces waiting time at that station. Thus, the passenger arrives 50 minutes earlier.
Example To outline the whole process let us give a real example. Assume a customer wanted to travel from Kaiserslautern to M¨onchengladbach and selected a connection with two interchanges, an interchange in Koblenz and one in D¨usseldorf.
- The first change went well but at 10:45, he receives a message that his train change in D¨usseldorf may fail.
- He logs on to our CoCoAS site and sees that 6 minutes are missing (at 10:50) to successfully complete the interchange (see Figure11.3).
Figure 11.5: CoCoAS example: Details of the first alternative at 10:50.
11.4 Others 185