UC:TT:Replacement Service Planning

Replacement Service Planning (RPLS) Subschema: Timetable and Rostering   Related subschemas: IS RS

DRAFT railML® version TBD

For general information on use cases see UC:Use cases

Use case / Anwendungsfall

Replacement Service Planning

Description / Beschreibung

The aim of the use case is to describe how a cancellation or partial cancellation is replaced by a substitute service. In this context, it is irrelevant whether the substitute service is rail-based or otherwise. However, the cancellation of a train is not a prerequisite for a substitute service.

The use case requires specific timetable data that describes actual operations. This data typically comes from a timetable planning system. In addition to passenger information systems, other possible consumers of the data include systems used to plan and manage bus services. Since the replacement services described may also be rail-based, fleet planning systems are also possible target systems for the data. Another conceivable class of target systems are reservation systems, so that they can send information about the changed operation to those customers who are affected by the replacement service.

Data Flows and Interfaces / Datenflüsse und Schnittstellen

Plans for replacement transport services can be made at short notice or well in advance. Accordingly, data for this use case can be exchanged in different cycles, depending on how the processes relating to replacement transport planning are organized.

Dependent railML^® domains / Abhängige railML^®-Domänen

The use case focuses on timetable and, where applicable, rollingstock data. Infrastructure data is only required in a reduced form, although detailed mapping of infrastructure by the use case is not excluded. Interlocking data is usually not exchanged in the context of this use case.

Characterizing Data / Charakterisierung der Daten

It must be possible to identify the type of replacement service, whether rail-bound or other. It must also be possible to identify the original services for which a replacement service was created and the reason for this. If a replacement service must be installed to compensate for reduced capacity, this should be reflected in the data. The replacement service itself can, but does not have to, be described within the railML document. It should be possible to refer to external services or to merely outline a replacement service.

The following data should be recorded for replacement transport services:

• Validity (via bit mask)
• ID
• Type of transport (rail, tram, bus, ferry, taxi, cable car, helicopter)
• Type of replacement transport (specific replacement or regular replacement service (regular: replaces line))
• What is being replaced
• If applicable, information for passenger information: URL would be useful for map reference to bus stop

It should also be possible to encode additional trips using the same mechanism.