UC:TT:DutyShiftsPersonnelRoster

From railML 3 Wiki
Revision as of 09:55, 22 September 2021 by RailML Coord Documentation (talk | contribs) (New UC)
Jump to navigation Jump to search
Duty planning and staff shifts
(SHFT)
Subschema: Timetable and Rostering
 
Related subschemas: IS RS 
Reported by: ÖBB
Stift.png (version(s) <version>)
For general information on use cases see UC:Use cases


Use case / Anwendungsfall

Exchange of planning results of a personnel duty scheduling system in the railroad sector with other systems, such as optimization systems, depot management systems, or employee support systems.

Description / Beschreibung

In the context of this use case, data determined as the results of a staff rostering process in corresponding systems are to be exchanged with other systems that further enrich or process them. Initially, the assignment of corresponding duty schedules to concrete personnel (i.e., employees) is to be explicitly disregarded. Such an assignment is regarded as processing in the consuming systems.

Data Flows and Interfaces / Datenflüsse und Schnittstellen

The data exchanged in the context of this use case is usually based on the data exchanged in the timetable. Typically, the data is planned for the long term and is calculated and exchanged for entire days. Short-term adjustments are made dispositively and without standardized data exchange.

Interference with other railML® schemas / Interferenz mit anderen railML®-Schemen

Elements of the infrastructure are referred to. Furthermore, <trains> or train sections, as well as validities from the timetable are referenced. If necessary, reference is also made to circulation data of the timetable.

Characterizing Data / Charakterisierung der Daten

A duty schedule in the sense of this use case describes the set of activities to be performed by an employee in a unit of time. The concrete employee should not be mentioned. Rather, abstract shift data should be exchanged.

How often do the data change (update)?

In the first step, a duration of 24 hours shall be assumed. It must be possible to support services that go beyond the daily limit.

How big are the data fragments to be exchanged (complexity)?

It must be possible to define recurring services compactly in order to be able to transfer the data with as little redundancy as possible. An activity is a single activity as part of a service. It can be, for example, ticket control, driving or even pausing. It is necessary to be able to capture the nature of each activity. Depending on the type of activity, it must be possible to transmit further data, for example:

  • ID for related service
  • Start and end of the planned activity
  • Start and destination of the activity
  • Train number of the train or train section (if corresponding to the type)
  • Train section (if appropriate to the type)
  • Required qualifications

Which views are represented by the data (focus)?

The Use Case builds on the Timetable Information Use Case, i.e., for services to be performed on a trip, the corresponding trips from the timetable are referenced. Accordingly, the requirements defined for this UC apply (UC:TT:TimetableInformation). In order to be able to easily communicate planning changes due to changes in operations, such as outages or partial outages, it should also be possible to identify services that have been cancelled. At a later stage, it should be explored whether it should also be possible to transfer outages of activities.

Which specific data do you expect to receive/send (elements)?

Glossary

  • Service - Shift - A sequence of activities to be carried out by an employee within the framework of a service shift
  • Activity - Task - Smallest unit in duty planning