Rail module concepts

The Rail module lets the 4PL prepare and follow a rail transport plan. It puts side by side what the customer expects (the reference trains, with their days and times), what the infrastructure manager grants (the train paths), and the gap between the two (the coverage). The four screens of the module handle the same objects: this page defines them once, the following pages refer back to it.

The timetable period

Everything starts with a timetable period: the validity period of a transport plan, usually an annual service. It has a code, a start date and an end date, and it holds everything else: the transport plans, the train paths, the links between them.

Every screen of the module works within one period at a time. The selector at the top left of the Reference transport plan and Train paths screens picks it; the dashboard offers the current period and the next one; the week view infers it from the displayed week. Without any period, nothing can be created: the message says so in plain words.

The reference transport plan and its relations

A reference transport plan (train offer, or simply “offer”) describes a reference train: its running days, its route from point to point, its customer times. It carries a train number (its name), a short number assigned automatically, an optional supplier (the railway undertaking) and axis, and technical constraints.

A transport plan is split into relations: commercial departure → arrival segments, chosen among the points of the route. When an offer is created, the main relation origin → destination is created automatically, named after the short codes of the points (LYO → MAR). Other relations can be added: a Lyon → Marseille train can carry a Lyon → Avignon relation and an Avignon → Marseille relation.

A relation also carries customer commitments: the volume of ITUs a principal commits to hand over on that relation, for an ITU category and a period. The whole offer carries ITU capacities: the number of ITUs of a given category the train can carry. An ITU is an intermodal transport unit: container, swap body, semi-trailer.

The train path

A train path is a running authorisation granted by the infrastructure manager, for a given route and times. It carries a number, and the same number can exist in several variants (v.1, v.2), for instance for different application days. It has a validity (start and end dates, within the period), running days, an optional supplier, technical constraints and a route.

The route of a train path is finer than that of an offer: besides the origin and the destination, it has typed intermediate points (Pick up / Drop off, Passing point, Driver change, Reversal, Running), each with its kilometre point and its times.

Coverage

Covering a relation means linking one or more train paths to it. A link ties a relation to a sequence of steps: each step uses a train path between a departure point and an arrival point, with a day offset +J. A relation can therefore be covered by a single train path end to end, or by several chained train paths whose points connect.

Coverage is read day by day, on the days the relation runs:

Over the whole period, these days give a coverage rate (share of running days covered) and a coverage status for the relation: Covered, Partial, Not covered, Over-covered. The dashboard and the screen filters reason on this status.

The application calendar

The running days of an offer or a train path form its application, also called its running days. It is made of:

• the ticked days of the week (the weekly pattern, Monday to Friday by default);
• plus dates added one by one, called included or AJJ;
• minus dates removed one by one, called excluded or RJJ.

A short label sums up the pattern (LU-VE). It is computed automatically and stays editable. The public holidays of a country can be removed or added in one go. For a train path, the application is bounded by its validity; for an offer, by the timetable period.

Times: HLR, MAD and +J

The times in the module are not limited to the departure and arrival of the train. They describe the full chain, from customer to customer:

At departure, the order is constrained: customer HLR < RU HLR < Departure. At arrival: Arrival < RU MAD < customer MAD. An HLR or a MAD can carry an equipment constraint: the time then only applies to a given equipment, and the same point can carry several.

The +J is the offset in days from the departure day at the origin. A train leaving at 22:00 and arriving at 06:00 arrives at 06:00 +1. The screens show it as an orange superscript wherever the arrival is not on the departure day.

Network points

A PR (network point) is a point on the rail network: station, terminal, junction. Routes are made of PRs; for an offer, only PRs with a terminal are offered. The PK (kilometre point) is the distance in kilometres from the origin of the route, increasing from point to point.

A Pick up / Drop off point is a point where wagons or ITUs are picked up or dropped off. These are the only points that carry HLRs and MADs, and the only ones that can serve as departure or arrival of a link step. A Passing point is crossed without stopping and has a single passing time.

Train path usage

Seen from the train path, the link reads the other way round: a train path is used by the relations linked to it. Its usage rate is the share of its running days actually used by relations. Its usage status follows: Used (fully), Partial, Over-used (too many offers on the same day), Unused (wasted capacity).

The application alignment compares, day by day, the application days of the train path with the use the offers make of it: Exact, Under-covered (days without an offer), Over-covered (several offers on the same day), Inconsistent (the days do not match).

Instantiation

A transport plan and a train path are references: they say what runs every Monday, not what runs on Monday 3 February. Instantiating means generating, for precise dates, the corresponding dated objects: dated trips for an offer, dated runs for a train path. Processing is asynchronous: a date first becomes in progress, then instantiated.

Rights

Access to the module and the actions on each screen depend on distinct rights. The guide recalls them under each action with the label “Required right”. Those that come up in the module:

Required right View the Rail moduleRead transport plansEdit transport plansDelete transport plansRead train pathsEdit train pathsDelete train pathsEdit customer commitmentsDelete customer commitments

• The account must have the Rail feature, otherwise the menu entry does not exist.
• The read right on an object opens its screen and its dashboard card; without it, the card does not appear.
• The edit right opens creation, modification, duplication, instantiation and links.
• The delete right is a separate right.
• An action that touches two objects requires both rights: “Create a train path from this plan” requires editing transport plans and editing train paths.

Where to find what