UC:TT:ServiceConceptTender
| Service Concept for a Tender Subschema: Timetable and Rostering Related subschemas: IS RS Reported by: iRFP | |||
| |||
| For general information on use cases see UC:Use cases |
Use case / Anwendungsfall
Service Concept for a Tender (call for proposals) Ausschreibungsfahrplan
Description / Beschreibung
The use case describes a timetable which is transferred
- from an authority issuing the invitation to bid
- to any potential bidder
with the aim to describe which timetable is asked for in the competition, i. e. the amount of trains, their routes and (regular) operating days and possible any other properties of the trains such as services or minimum seating capacities.
The background behind such a data exchange with railML® files is, especially at competitions of large production amount, it will be easier for the bidders to reproduce the timetable in their own software systems. This allows a quicker calculation e. g. of the number of vehicles necessary or, at least, the price. Time consuming and potential faulty manual transcription of the timetable shall be avoided. The usage of railML® for such a data exchange (instead of more special file formats) shall keep this procedure transparent and non-discriminating.
The main intention of the use case is passenger traffic since the number of trains and the extent of the timetables is typically more complex than in freight traffic. But it may also be used for freight traffic.
The timetable data described as part of this use case can be based on an existing infrastructure and/or rolling stock as well as on a future planned and even conceptual state of infrastructure and rolling stock. The states are to be described in the railML file.
Often the response to a timetable prepared with this use case complies with the requirements described in the use case LTST (link to the railML® website).
Data Flows and Interfaces / Datenflüsse und Schnittstellen
The use case covers a one-direction data exchange only; a possibly offered timetable (from bidder to authority) is not part of this use case.
Such data exchange is described in the use case Long Term Strategic Timetable (link to the railML® website) and potentially Long Term Circulation Planning (link to the railML® website). The authority issuing the invitation to bid should specify which UC the response delivery is expected to follow.
The data exchanged for this use case typically includes a description of the commercial trains with their routes and timings. The level of detail of the included infrastructure data varies. As a minimum the operational points need to be exchanged, however also the exchange of more detailed infrastructure information is possible, such as <lines>, <tracks>, track <geometry> including gradients and super-elevations, <speeds> and so on.
The data may optionally include information about the used vehicles and formations. It may or may not include a description of the timetable period in question. The exchanged information may also already contain circulation plans, although often this is not the case.
Interference with other railML schemas / Interferenz mit anderen railML-Schemas
Typically, the information involved in data exchanges for this use case includes infrastructure data, rolling stock and timetable data. Infrastructure data often is only limited. The minimum infrastructure data required for this use case are operational points each specifying designators in common registers allowing importing systems to map the operational points to locally available data sets.
Characterizing Data / Charakterisierung der Daten
The data exchanged with this use case is to be considered long term planning (LTP 4-1 year ahead of operations) or even very long term planning (VLTP; 15-4 year ahead of operations) in scope.
Typically, only essential infrastructure data is included in the data exchange. This is mainly because the issuing authority is usually not identical with the infrastructure manager. Nevertheless, general infrastructure information is provided to bidders as part of the tender process, effectively passed on from the infrastructure manager(s) via the issuing authority. In some cases, the relevant infrastructure data may be included in the same railML® file as the timetable. However, with the establishment of national infrastructure registers, it is expected that such information will increasingly be referenced from, or extracted into, separate documents - potentially railML® files - corresponding to these registers.
In all cases, operational points must be included, as no timetable can be defined without them. Lines and tracks may be added where necessary to accurately describe a train’s route, particularly in areas with complex infrastructure, such as parallel lines. Additional infrastructure data — such as gradients, speed profiles, and similar parameters — fall rather under the considerations outlined in the previous paragraph.
Typically, there is no timetable period for timetables of this use case. The timetable is valid not for a certain but several years which are not specified in the railML® file.
The operating periods of the trains are based on generic weekdays only with no reference to specific dates. The timetables are typically not planned regarding public holidays or such; the amount of train kilometres a. s. o. is only calculated on a statistical basis (flat number of operating days, statistic year).
The primary reason to include a reference to a timetable year is to enable the description of seasonal train services, such as school trains or summer-only operations. For this purpose, it must be possible to encode this type of information within the timetable data.
The data set usually does not include real existing vehicles nor formations for non-discrimination reasons. There shall be included a conceptual master vehicle for the sub use cases/purpose of:
- Run-time calculation for the timetable design (see separate RTCI-b UC (link to the railML® website))
- Dwell time calculation (passenger flow rate) for the timetable design (see SCOT-b (link to the railML® website))
- Transportation capacity and quality
- Interoperability requirements
The master vehicle can be an obfuscated existing vehicle or a conceptual/theoretical one. Both with the required minimum characteristics for the timetable concept. It is common to publish this master vehicle with the call for tenders. If the vehicles are allocated there is no reason to exclude them from the timetable.
An example for such a master vehicle would be Jernbanedirektoratets “Standardtogtyper”
Typically, the preparation of circulation plans (vehicle rostering) is the responsibility of the bidder; therefore, such plans are generally not included in the data exchange. This is mainly because neither the type and capacity of the vehicles nor the locations of the depots are known in advance. Conversely, even when vehicles are predefined or allocated, bidders are often required to submit their own circulation plans as evidence of their operational competence. However, if the contracting authority provides its own vehicles for operation on the specified infrastructure, circulation data are included in the exchanged dataset.
Sub use cases
The use case is sub divided into three sub use cases:
- SCOT-a: related to the infrastructure elements required in the use case
- SCOT-b: related to the rolling stock elements required in the use case
- SCOT-c: related to the timetable elements required in the use case
SCOT-a
A timetable can only be created after a runtime calculation has been performed. Therefore, the SCOT-a use case is based on the RTCI-a UC (link to the railML® website). For detailed information, refer to the Runtime Calculation Input Data (link to the railML® website) use case description.
SCOT-b
This sub-use case is focused on the properties of the rolling stock for the following aspects:
- Runtime calculation for timetable design
- Dwell time calculation for timetable design
- Transportation capacity and quality
- Interoperability requirements
A timetable can only be created after a runtime calculation has been performed. Therefore, the SCOT-b use case is based on the RTCI-b (link to the railML® website) use case. For detailed information, refer to the Runtime Calculation Input Data (link to the railML® website) use case description. Dwell time calculation (passenger flow rate) for the timetable design To enable the timetable planner to determine the correct station dwell time, the alighting rate shall be determinable based on influencing parameters such as door width and the gap between the door and the platform.
Transportation capacity and quality
Transport capacity varies depending on place quality. Higher-quality places typically provide more space per place (e.g. first-class seating) than lower-quality places (e.g. standing places). Certain services (e.g. toilets) and place quality levels (e.g. seating) shall be definable. For example, place categories such as seat A/B/C and standing A/B/C (place-based versus area-based, in use / not in use) shall be supported. In addition, further required onboard services shall be describable (e.g. facilities for persons with reduced mobility).
Interoperability requirements
This topic covers technical requirements such as signalling systems, gauge, and clearance profile, and is based on the ROCO (link to the railML® website) use case. For detailed information, refer to the Route Compatibility Check (ROCO) use case description.
Relationship between SCOT-b and -c request and LTST-c use case offer
The structures for modelling rolling stock passenger facilities are identical in the Rollingstock schema and the Timetable schema. Therefore, passenger facilities shall be defined in the Rollingstock schema either as minimum requirements or as technically feasible values. These definitions shall be provided in the rolling stock metadata. It shall be possible to communicate the requirements regarding passenger and freight facilities as well as other aspects of the requirements a vehicle needs to fulfill for the described service concept.
The passenger facilities defined in the timetable schema within the LTST-c use case and offered by the bidder shall constitute the proposed offer. For example, the tender may define a minimum requirement of a rolling stock master vehicle with 50 first-class places, while the bidder may offer a vehicle with 55 first-class places in the proposal.
SCOT-c
A service concept describes the intended revenue-generating train service within a defined area, i.e. the train operations available to passengers or freight. It excludes empty trains and other non-revenue movements required to provide train departures in accordance with published timetables. In passenger services, the concept represents what is perceived by passengers as “the service”.
A service concept can be developed for current and future time horizons, but it is often used for long-term planning when the timetable is not yet known.
A service concept is defined by the following elements:
- The line concept (service itinerary), including the stopping pattern (see RTCI-c UC (link to the railML® website))
- Running time, or target running times
- Service frequency, including any fixed intervals (if fixed interval, usually described via <patternTrains>)
- Daily distribution (number of trains per hour over a standard 24-hour day)
- References to the master vehicle used on each line, thus providing basic planning data
- State information describing the planning state of the trains
Future service concepts provide the analytical basis for capacity assessments, the identification of infrastructure needs, and transport model calculations.