UC:TT:DutyShiftsPersonnelRoster

From railML 2 Wiki
Revision as of 11:05, 18 July 2022 by RailML Coord Documentation (talk | contribs) (+mirror)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
🗒️ This page is mirrored from page UC:TT:DutyShiftsPersonnelRoster in The railML® 3 wiki.
Duty planning and staff shifts
(SHFT)
Subschema: Timetable and Rostering
 
Related subschemas: IS RS 
Reported by: ÖBB Personenverkehr
Stift.png (version(s) not yet specified)
For general information on use cases see UC:Use cases


Use case / Anwendungsfall

Austausch von Planungsergebnissen einer Personal-Dienstplanung im Bahnsektor mit anderen Systemen, etwa Optimierungssystemen, Betriebshofmanagementsystemen oder Supportsystemen der Beschäftigten.

Beschreibung

Im Rahmen dieses Use Case sollen Daten, die als Ergebnisse einer Dienstplanung in entsprechenden Systemen ermittelt wurden, mit anderen Systemen ausgetauscht werden, die diese weiter anreichern oder verarbeiten. Dabei soll zunächst explizit auf die Zuordnung von entsprechenden Dienstplänen zu konkreten Personalen (also Mitarbeitern) abgesehen werden. Eine solche Zuordnung wird als Verarbeitung in den konsumierenden Systemen angesehen.

Datenflüsse und Schnittstellen

Die Daten, die im Rahmen dieses Use Case ausgetauscht werden, orientieren sich üblicherweise an denen, des ebenfalls ausgetauschten Fahrplans. Typischerweise handelt es sich um eher langfristig geplante Daten, die für ganze Tage errechnet und ausgetauscht werden. Kurzfristige Anpassungen werden dispositiv und ohne standardisierten Datenaustausch vorgenommen.

Interferenz mit anderen railML-Schemen

Es wird auf Elemente der Infrastruktur verwiesen. Weiterhin wird auf Züge oder Zugteile, sowie Gültigkeiten aus dem Fahrplan verwiesen. Ggf. wird auch auf Umlaufdaten des Fahrplans verwiesen.

Charakterisierung der Daten

Eine Dienstplanung im Sinne dieses Use Case beschreibt die Menge von Tätigkeiten , die durch einen Mitarbeiter in einer Zeiteinheit durchgeführt werden sollen. Dabei soll der konkrete Mitarbeiter keine Erwähnung finden. Es sollen vielmehr abstrakte Schichtdaten ausgetauscht werden. Im ersten Schritt soll von einer Dauer von 24 Stunden ausgegangen werden. Dienste, die über die Tagesgrenze gehen, müssen unterstützt werden können. Es muss möglich sein, wiederkehrende Dienste kompakt zu definieren, um die Daten mit möglichst geringer Redundanz übertragen zu können. Bei einer Tätigkeit handelt es sich um eine einzelne Aktivität als Teil eines Dienstes. Es kann sich dabei etwa um Fahrkartenkontrolle, Fahren oder auch Pausieren handeln. Es ist erforderlich die Art einer jeden Tätigkeit erfassen zu können. Je nach Art der Tätigkeit muss es möglich sein, weitere Daten zu übermitteln, bspw.:

  • ID für zugehörigen Dienst
  • Beginn und Ende der geplanten Tätigkeit
  • Start- und Zielort der Tätigkeit
  • Zugnummer des Zuges bzw. Zugabschnitt (sofern der Art entsprechend)
  • Zugteil (sofern der Art entsprechend)
  • Erforderliche Qualifikationen

Der Use Case baut auf dem Use Case Fahrplanauskunft auf, das heißt für Dienste, die auf einer Fahrt durchgeführt werden sollen, wird auf die entsprechenden Fahrten aus dem Fahrplan verwiesen. Entsprechend gelten die Anforderungen, die für diesen UC definiert wurden (UC:TT:TimetableInformation). Um Planungsänderungen aufgrund von veränderten Betriebsabläufen, wie etwa Ausfällen oder Teilausfällen, einfach kommunizieren zu können, sollten auch ausgefallene Dienste erkennbar sein. Im späteren Verlauf sollte eruiert werden, ob auch eine Übertragung von Ausfällen von Tätigkeiten möglich gemacht werden sollte.

Glossar

  • Dienst - Shift - Eine Folge von Tätigkeiten die durch einen Mitarbeiter im Rahmen einer Dienstschicht durchgeführt werden soll
  • Tätigkeit - Task - Kleinste Einheit bei der Dienstplanung