E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU 260417.pdf

[Seite 1]

Anlage 17

RMV-Datenhandbuch

Datenlieferungen und -strukturen

für die Partner des RMV

Version 3.47.00

Stand: 17.04.2026

RMV GmbH, Hofheim. Alle Rechte vorbehalten

[Seite 2]

Inhalt

Verzeichnis der Anhänge 4

Verzeichnis der Abbildungen 4

Verzeichnis der Tabellen 4

1. Vorwort 5

2. Datenübertragung 6

2.1. Physikalische Übertragung 6

2.2. Datenkodierung 6

2.3. Dateinamen 6

2.4. Dateistruktur 6

2.5. Kompatibilität 6

3. Dateninhalte 7

3.1. Fahrplanvorgabe für die Angebotserstellung 7 3.1.1. Geografische Netzdaten 7 3.1.2. Fahrplandaten 7

3.2. Umsetzung des Leistungsangebots 7 3.2.1. Netzdaten 7 3.2.1.1. Haltestellen und Stationen 7 3.2.1.1.1. Haltestellen-Identifikationsmerkmale 7 3.2.1.1.2. Umgebungsplan und Haltestellen-Hierarchie 8 3.2.1.1.3. Geographische Haltestellen-Merkmale 9 3.2.1.1.4. Tarifliche Haltestellen-Merkmale 9 3.2.1.2. Linien 9 3.2.1.3. Fahrwege 9 3.2.2. Soll-Fahrplan 9 3.2.2.1. Fahrplandaten 9 3.2.2.1.1. Leistungsänderungen 10 3.2.2.2. Kapazitätsmeldung im SPNV (PLAN) 10 3.2.3. Aktuelle Daten zum Betriebsablauf 14 3.2.3.1. Grundsätzliches 14 3.2.3.2. Positionserfassung 14 3.2.3.3. Leitsystem (allgemein) 14 3.2.3.3.1. Leitsystemzusatz für Schienenpersonennahverkehr (SPNV) 16 3.2.3.4. Technische Schnittstellen 16 3.2.3.4.1. Anwendungsfall „Fahrplanauskunft“ 16 3.2.3.4.2. Anwendungsfall „Fahrgastinformation an Stationen bzw. im Fahrzeug“ 16 3.2.3.4.3. Anwendungsfall „Anschlussmanagement“ 16 3.2.3.4.4. Visualisierung von Fahrzeugpositionen 17 3.2.3.5. Zuzuliefernde Daten und Fristen 17 3.2.3.5.1. Sachlicher Umfang 17 3.2.3.5.2. Metadaten 17 3.2.3.5.3. Istdaten 18 3.2.3.5.4. Prognosedaten 18

3.3. Qualitätsdaten BPNV 20 3.3.1. Automatische Pünktlichkeitserfassung im BPNV 20 3.3.1.1. Zielstellung 20 3.3.1.2. Systembeschreibung 20

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 2 von 41

[Seite 3]

3.3.2. Pünktlichkeitsdaten im BPNV 21 3.3.3. Ausfall oder Teilausfalldaten / Einsatz Fahrzeuge mit abweichender Antriebsart 23

3.4. Qualitätsdaten SPNV 26 3.4.1. Pünktlichkeitsdaten im SPNV 26 3.4.1.1. Pünktlichkeitsdaten im SPNV als PAD Lieferung 26 3.4.1.2. Verspätungsursachen im SPNV ergänzend zur PAD Pünktlichkeitslieferung 27 3.4.2. Ausfalldaten, Ersatzfahrzeuge, BNV bzw. SEV im SPNV 27 3.4.3. Kapazitätsmeldung im SPNV (IST) 30

3.5. Zähldaten der automatischen Fahrgastzählung (AFZS) im SPNV 31 3.5.1. Einleitung 31 3.5.2. Normative Grundlagen und Vorrang 32 3.5.3. Lieferobjekt, Turnus und Abgrenzungen 32 3.5.4. Rohdaten gemäß VDV 457-2 (XML) 32 3.5.4.1. Allgemeines / Validierung 32 3.5.4.2. Zulässige Granularitäten der Rohdaten-Dateien 32 3.5.4.3. Dateibenennung Rohdaten 33 3.5.5. Ergebnis-/Protokollartefakt der Transformation und Zuordnung 33 3.5.5.1. Zweck 33 3.5.5.2. Mindestinhalt 33 3.5.5.3. Format und Benennung 33 3.5.6. Liefermanifest als Vollständigkeitsnachweis 33 3.5.7. Monatliche Vollständigkeitsübersicht 34 3.5.8. Technische Grundlagen Bestandsformat RMV 34 3.5.8.1. Dateiaufbau 34 3.5.8.2. Dateibezeichnung 34 3.5.8.3. Datei-Inhalt 35 3.5.8.4. Spaltenformat 35 3.5.9. Tabellenmodell 35 3.5.9.1. AFZS Zählfahrt-Tabelle 35 3.5.9.2. Haltestellen-Tabelle für AFZS Zählfahrten 36

4. Glossar, Begriffsdefinitionen 37

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 3 von 41

[Seite 4]

Verzeichnis der Anhänge

Anhang 1: entfällt

Anhang 2: Transform_HAFAS-Rohdaten-Vers_5.40.13-7-stellig_(Fahrplandaten) (Haltestellenscharf),

Transform_HAFAS-Rohdaten-Vers_5.40.13-9-stellig_(Fahrplandaten) (Mastscharf)

Anhang 3: ISA-Format (Fahrplan), Vers. 3.0 bis 5.7

Anhang 4: VDV 451 ( ÖPNV Datenmodell 5.0 ) Stand 1999,

VDV 452 ( ÖPNV Datenmodell 5.0 ) Version 1.6.1

Anhang 5: VDV 453 und VDV 454 (Ist-Daten-Schnittstelle), Vers. 3.1, Stand 08/2024

Anhang 6: OPENDATA_API_Abruf_Online-Fahrplandaten, Stand 14.05.2025

Anhang 7: entfällt

Anhang 8: Vorgaben zu den Schnittstellen VDV 453 und VDV 454

Anhang 9: VDV 457 AFZS (insb. 457-2 Rohdaten, 457-3 Ergebnisdaten), Vers. 2.3, Stand 11/25

Anhang 10: VDV 713-0-1 Auslastungsinformationen, Stand 9/23

Verzeichnis der Abbildungen

Abb. 1: Überblick Prognosedatenfluss inkl. Anschlusssicherung

Abb. 2: Lieferweg der Verkaufsdaten bei lokalen, regionalen und gemischten Bündeln

Verzeichnis der Tabellen

Tabelle 1.1: Fahrplan Importformate

Tabelle 1.2: Header Importformat Kapazitätsmeldung im SPNV (PLAN)

Tabelle 1.3: Importformat Kapazitätsmeldung im SPNV (PLAN)

Tabelle 2.1: Kodierungen der Verspätungsursachen

Tabelle 2.2: Datenformat Meldung der Pünktlichkeitsdaten im BPNV

Tabelle 3.1: Kodierungen der Ausfallursachen

Tabelle 3.2: Datenformat Meldung der Ausfall- / Teilausfalldaten / Einsatz abweichender Antriebsarten

Tabelle 4.1: Attribute in PAD-Datenlieferung (Pünktlichkeitsdaten) im SPNV

Tabelle 4.2: Attribute in SZU-Datenlieferung im SPNV

Tabelle 5.1: Datenformat Meldung der Ausfall- oder Teilausfalldaten / Ersatzfahrzeuge / BNV bzw. SEV im SPNV

Tabelle 5.2: Importformat Kapazitätsmeldung im SPNV (IST)

Tabelle 6: Übersicht Spaltentypen bei AFZS-Meldungen

Tabelle 7: AFZS Zählfahrt-Tabelle

Tabelle 8: Haltestellen-Tabelle für AFZS Zählfahrten

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 4 von 41

[Seite 5]

1. Vorwort

Um die Aufgaben der Koordination, Planung und Bestellung von Betriebsleistung sowie die Aspekte der Qua- litätskontrolle- und Sicherung, der Kundeninformation und des Vertriebs in ausreichender Qualität sicherstel- len zu können, sind zwischen der RMV GmbH und den Partnern entsprechende prozessbegleitende Daten- lieferungen in definierten Strukturen und Lieferzyklen notwendig und auf jeden Fall einzuhalten.

Die genauen Lieferzeitpunkte werden in den Vertragsunterlagen geregelt.

Sämtliche Datenlieferungen erfolgen grundsätzlich an den Bereich IT der RMV GmbH. Im Einvernehmen mit dem Bereich IT und dem zuständigen Fachbereich können auch andere Lieferadressen, wie z.B. der Fach- bereich selbst oder externe Dienstleister, vereinbart werden.

Die vorliegende Anlage präzisiert daher IT-technisch die Regelungen für die Realisierung im täglichen Betrieb und der Umsetzung.

Der Auftragnehmer (AN) räumt dem Auftraggeber (AG) an den gemäß den Vertragsunterlagen kostenlos zur Verfügung gestellten Fahrplandaten (Soll-Daten), Pünktlichkeitsdaten sowie sämtliche Daten zum aktuellen Betriebsablauf (Ist-Daten, vgl. auch Ziffer 3.2.3) ein zeitlich und räumlich unbeschränktes, umfassendes und ausschließliches Nutzungs- und Verwertungsrecht ein. Hierdurch entstehen für den AG keine weiteren Ver- pflichtungen. Die Nutzung und Verwertung dieser Daten durch den AN zum Zwecke der Vertragserfüllung ist weiterhin gestattet.

Alle Grafiken in dieser Anlage dienen nur der Illustration, verbindlich sind alleine die textlichen Beschreibun- gen.

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 5 von 41

[Seite 6]

2. Datenübertragung

2.1. Physikalische Übertragung

Sofern im jeweiligen Abschnitt der Vertragsunterlagen nichts anderes geregelt ist, hat die Datenübertragung im Regelfall über eine geschützte IP-Verbindung (Internetprotokoll) zu erfolgen.

In Abstimmung mit dem AG können Daten auch per E-Mail übertragen werden. Sämtliche prozessbegleitende Dokumente sind, auch wenn sie nochmals in Papierform mit Unterschrift gesendet werden, auf jeden Fall per E-Mail zu übermitteln.

Vertrauliche Daten sind, auch bei der Übertragung via E-Mail, zu schützen. Ein geeignetes Verfahren ist mit dem AG abzustimmen.

2.2. Datenkodierung

Die in dieser Anlage beschriebenen Datenlieferungen sind, wenn nicht explizit anders definiert, in UTF-8 zu codieren.

Dabei soll nach Möglichkeit auf die BOM (Byte Order Mark) am Anfang des Datenstroms bzw. der Datei verzichtet werden, es sei denn es ist im konkreten Fall anders gefordert. Eine Lieferung mit BOM wird nicht beanstandet. zu BOM: siehe auch: http://de.wikipedia.org/wiki/Byte_Order_Mark (Stand 15.7.2013)

2.3. Dateinamen

Sofern im entsprechenden Abschnitt der Dateiname einer (dateibasierten) Datenlieferung nicht explizit be- schrieben ist sind folgende Regeln für Dateinamen zu beachten:

Im Dateinamen wird nur eine Untermenge der 7-Bit ASCII Zeichen verwendet.

Es gilt einschränkend: Der Dateiname enthält nur Zeichen des nachfolgenden Zeichenvorrats

{A..Z, a..z, 0..9, "-", ".", "_", "#", "&", "$", "%", "°"}, also insbesondere keine Umlaute, Klammern, Leerzeichen, Satzzeichen (Punkt siehe unten) und als Sonderzeichen nur die acht dargestellten.

Es muss genau ein Punkt im Dateinamen als Trennung zur (wenn nicht anders vermerkt) dreistelligen Exten- sion (die letzten drei Zeichen des Dateinamens nach dem Punkt) vorkommen.

2.4. Dateistruktur

Zum Aufbau der Datei (z.B. Feldtrennung, Datensatztrennung) ist insbesondere bei csv Dateien der Abschnitt „csv“ im Glossar dieses Dokuments zu beachten.

2.5. Kompatibilität

Sofern VDV-Schnittstellen vorgegeben sind, müssen die Schnittstellen und Datenformate grundsätzlich VDV- Kompatibilität gemäß VDV-Schriften besitzen. Darüber hinausgehende Anforderungen durch das hier vorlie- gende Dokument sind davon unberührt zu gewährleisten. Sollten sich die Vorgaben technisch gegenseitig ausschließen hat das vorliegende Dokument Vorrang, ausgenommen es liegen spezifische Vereinbarungen vor.

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 6 von 41

[Seite 7]

3. Dateninhalte

Zwischen dem AG und dem AN sind in allen Phasen der Zusammenarbeit folgende Datenlieferungen zu ge- währleisten.

3.1. Fahrplanvorgabe für die Angebotserstellung

Die vom AG gegebenenfalls elektronisch zur Verfügung gestellten Fahrplandaten werden wie nachfolgend beschrieben geliefert.

3.1.1. Geografische Netzdaten

Die den ausgeschriebenen Linien zugrunde liegenden Streckenverläufe werden durch den RMV zur Illustra- tion als geographische Linienverläufe in einem (nicht routingfähigen) gebräuchlichen elektronischen Format zur Verfügung gestellt.

3.1.2. Fahrplandaten

Seitens des RMV können die Übersichtstabellen im „.xlsx“ Format sowie die Fahrplandaten im transform- (Anhang 2) und im ISA-Format (Anhang 3) geliefert werden.

3.2. Umsetzung des Leistungsangebots

Die Fahrplandaten inkl. geografischer Streckeninformationen für den jeweiligen Jahresfahrplan einschließlich unterjähriger Änderungen sind vom AN entsprechend den in den folgenden Ziffern beschriebenen Vorgaben an den AG zu liefern. Grundsätzliche kundenwirksame Identifikationsmerkmale wie z.B. Haltestellenbezeich- nung und Linienbezeichnung sind mit ihren jeweils aktuellen Werten und Inhalten einzusetzen und dürfen nicht geändert werden.

3.2.1. Netzdaten

Die Netzdaten werden grundsätzlich zwischen AG und AN mit den nachfolgend beschriebenen Attributen gegenseitig ausgetauscht.

3.2.1.1. Haltestellen und Stationen

Bei Haltestellen und Stationen ist grundsätzlich zwischen den Identifikationsmerkmalen, die in der Regel in Fahrplansystemen gepflegt werden, den geographischen, den tariflichen und den Ausstattungsmerkmalen zu unterscheiden, die oft in getrennten Haltestellen- oder Stationskatastern gepflegt werden.

Die verbindliche Quelle der relevanten Haltestellendaten wird seitens des RMV in Form der Tarifdaten früh- zeitig vor jedem Tarifwechsel bereitgestellt.

3.2.1.1.1. Haltestellen-Identifikationsmerkmale

Zur eindeutigen Identifikation der Haltestellen und / oder Masten wird folgendes Merkmal verwendet:

DHID (siehe Glossar) bis zur Ebene 3 (Hst) oder bis zur Ebene 5 (Mast)

Die bislang im RMV verwendete

Haltestellen-Nummer (RMV_ID_Hst_Nr).

ist nur noch auslaufend bei einigen Qualitätsdatenlieferungen bis zur Ablösung des im RMV verwendeten Systems zugelassen.

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 7 von 41

[Seite 8]

Weitere unverzichtbare Attribute einer Haltestelle sind:

• Landkreis

• Kommune

• Ortsteil (Stadtteil)

• Haltestellenname in unterschiedlicher Ausprägung

(ohne / mit Ortsteilname (max. 30 Zeichen), Voll- / Kurzbezeichnung)

• tarifliche Merkmale wie vom RMV vorgegeben

• Koordinaten (siehe folgende Absätze)

• DHID - deutschlandweit eindeutige Haltestellen-ID, bei Lieferung von Fahrplandaten bis zur Mastebene

Diese Haltestellendaten werden vom AG dem AN initial auf Anforderung für die benötigten Haltestellen inner- halb der Tarifdaten zur Verfügung gestellt. Der AG behält sich vor dem AN optional einen Zugang zu einem online Haltestellen-Management-System oder den Bezug aktueller Haltestelleninformationen auf andere Weise über einen Online-Zugang oder einen Downloadlink zur Verfügung zu stellen.

Wichtiger Hinweis: Einführung deutschlandweit eindeutige Haltestellen-ID (DHID)

Die seit 2016 eingeführte deutschlandweit eindeutige Haltestellen-ID „DHID“ ist in diesem Dokument Grund- lage der vertraglichen Anforderungen hinsichtlich Speicherung und Übermittlung von Haltestellen-IDs. Hierzu ist durchgehend ein alphanumerischer Datentyp von 40 Zeichen Länge definiert und gefordert. Für die meis- ten IT-Systeme war hierzu eine entsprechende Anpassung notwendig. Häufig wird in bestehenden Software Systemen die DHID als zusätzliches Attribut zur bestehenden intern genutzten Haltestellen ID in den Daten gespeichert bzw. geliefert.

Die durch den RMV eingesetzten Daten enthalten parallel vielfach noch die herkömmlichen numerischen IDs für Haltestellen oder Haltestellenmaste. Im vorliegenden Dokument sind alle relevanten Datenlieferung nun auf die DHID umgestellt.

Die in diesem Dokument verbindlich definierte Anforderung an die Speicherung und Verarbeitung von Halte- stellen-IDs fordert (in allen betroffenen Datenstrukturen) einen

• Typ alphanumerisch, Länge bis zu 40 Zeichen Inhalt.

Weiteres zum Thema siehe Glossar am Ende dieses Dokuments unter „Globale Haltestellen-ID“.

3.2.1.1.2. Umgebungsplan und Haltestellen-Hierarchie

Bei Stationen schienenbetriebener Verkehrsmittel sowie komplexen Haltestellen wie bspw. ZOB’s wird auf Nachfrage vom AG ein Umgebungsplan mit Zu- und Abgängen zu Gebäuden und Steigen zur Verfügung gestellt.

Haltestellen sind grundsätzlich in einer mindestens dreistufigen hierarchischen Struktur organisiert: Jede Hal- testelle enthält Haltestellenbereiche und diese wiederum Haltestellenmasten.

Im Schienenbereich entspricht dem Haltestellenbereich der Bahnsteig, dem Haltestellenmast entspricht das Gleis. Hinzu kommt mit Einführung der globalen Haltestellen-ID als vierte Strukturebene einer Haltestelle der Gleisabschnitt (vor Ort meist mit Großbuchstaben gekennzeichnet). Bei Haltestellen und Stationen sind die entsprechenden Über- und Unterordnungsbeziehungen von Haltestelle, Haltestellenbereichen und Haltestel- lenmasten zu berücksichtigen.

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 8 von 41

[Seite 9]

3.2.1.1.3. Geographische Haltestellen-Merkmale

Die geographische Lage der Masten wird mit Koordinaten für Länge, Breite und (gegebenenfalls) Höhe über N.N. mit einer Messungenauigkeit von max. 3 Meter im Gauß-Krüger-Format (Zone 3) bestimmt. In den Ta- rifdaten werden die Koordinaten zusätzlich auch noch im WGS84 Format bereitgestellt.

3.2.1.1.4. Tarifliche Haltestellen-Merkmale

Die tariflichen Merkmale einer Haltestelle werden vom AG vorgegeben und vollständig in den Tarifdaten be- reitgestellt.

3.2.1.2. Linien

Für die ausgeschriebenen Linien werden vom AG alle Unterlinien mit ihrem geographischen Verlauf gepflegt. Verfügbare Datenformate in der jeweils dem technischen Stand entsprechenden Version:

• Transform-Format inkl. Realgraf-Export (siehe Anhang 2)

• ISA-Format (siehe Anhang 3)

Beim Datenaustausch ist, wo technisch bereits unterstützt, immer die DLID, (deutschlandweit eindeutige Linien-ID) mitzuliefern.

3.2.1.3. Fahrwege

Änderungen im geografischen Verlauf von Fahrwegen sind dem AG rechtzeitig mitzuteilen.

3.2.2. Soll-Fahrplan

3.2.2.1. Fahrplandaten

Der AN muss einen Grundfahrplan aus seinem Fahrplanungsprogramm liefern, welches eine Schnittstelle zu ivu.pool bedienen kann. Eine Lieferung im „.xlsx“ Format ist somit vertragsgemäß nicht zulässig.

Bei der Lieferung der Fahrplandaten können folgende Datenformate Verwendung finden:

Tabelle 1.1: Fahrplan Importformate

Weitere Datenformate und Ergänzungslieferungen können in Abstimmung mit der RMV IT vereinbart werden. Insbesondere aufgrund technischer Weiterentwicklung ist hier in enger Abstimmung mit der RMV IT der Lie- ferprozess an die technischen Möglichkeiten anzupassen um das Ziel einer aktuellen, umfassenden Informa- tion der Kunden hinsichtlich des Fahrplans einerseits mit möglichst stark automatisierten Fahrplanimportpro- zessen andererseits zu gewährleisten.

Die in den Fahrplandaten referenzierten Haltestellen sind durch ihre DHID repräsentiert. Dabei ist der Fahr- plan mastscharf zu liefern. D.h. die DHID ist bis zur Mastebene (Ebene 5) zu liefern.

Die in den gelieferten Fahrplandaten referenzierten Linien sind inklusive ihrer DLID zu liefern.

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 9 von 41

[Seite 10]

Hinweis bei Lieferungen im Format railML:

Sofern die Fahrplandaten Verkehre mit Flügelung enthalten, ist eine railML Lieferung (ab FPL-Jahr 2021/22) in den Formaten 2.2 oder höher verpflichtend.

Dabei ist insbesondere bei den die Flügelung betreffenden Inhalten zu bedenken, dass eine vertrags- konforme Lieferung von Prognoseinformationen (gemäß den in Kap 3.2.3 beschriebenen Verfahren) zu gewährleisten ist.

Sämtliche Merkmale, die für eine Auskunft entsprechend BGG (Gesetz zur Gleichstellung behinderter Men- schen) notwendig und in dem verwendeten Format enthalten sind, müssen auch geliefert werden. Es sind dies z.B. die korrekte Gleisbelegung aus Kundensicht bzw. der korrekte Haltemast an jeder Haltestelle sowie der Fahrzeugtyp mit den relevanten Informationen (Niederflur, Tritthöhe, Rampe, ...) so wie sie in der detail- lierten Formatbeschreibung, z.B. ISA- oder VDV-Format, in den Anhängen 3 und 4 definiert sind.

Im BPNV sind die in den Vertragsunterlagen definierten Fahrtnummern mitzuliefern.

Im SPNV sind die von der DB InfraGO vorgegebenen Zugnummern mitzuliefern.

Darüber hinaus ist immer der geplante Fahrzeugtyp für jede Fahrt zu liefern. Nachfolgend Beispiele:

• Im Schienenverkehr: z.B. Itino, VT612, VT628, VT629, Coradia Lint, Desiro, ET425

• Im Busverkehr: z.B. Niederflur mit/ohne Rampe und Fahrzeugbodenhöhe 24/27 cm bzw. Hochflurfahrzeug mit 1 bzw. 3 Stufen

3.2.2.1.1. Leistungsänderungen

Durch Änderungen der geplanten Leistung kann es während der Fahrplanperiode zu Änderungen des Soll- fahrplans kommen. In diesem Fall müssen nur die Daten der geänderten Linien geliefert werden.

Die Daten sind gemäß dem Planungskalender des RMV zu liefern, damit die Kommunikationsmittel des RMV (z.B. https://www.rmv.de) rechtzeitig aktualisiert werden können.

Unbedingten Vorrang hat die Identität der gelieferten Solldaten mit dem Sollzustand im RBL/ITCS um eine eindeutige und sichere Zuordnung für die Prognosemeldungen herstellen zu können („Matching“). Siehe dazu die konkreten Formulierungen in Anhang 8. Leistungsänderungen (Störungen) wie Baustellen und Umlei- tungsverkehre sind als Solldaten zu liefern. Um oben genannte Identität zwischen Solldaten und ITCS sicher- zustellen sind im Falle der NICHT-Lieferung geänderter Solldaten die Änderungen als dispositive Maßnah- men im Leitsystem (siehe Anhang 8) zu melden.

Für den SPNV gilt insbesondere, dass die seitens eines SEV tatsächlich angefahrenen Haltepunkte geliefert werden (und nicht der ggf. abweichende, im ursprünglichen Sollfahrplan genannte Bahnhof).

3.2.2.2. Kapazitätsmeldung im SPNV (PLAN)

Für den SPNV hat der AN gemäß nachfolgender Datenstruktur die Kapazitätsmeldungen zur geplanten Fahr- zeugbehängung (Traktion / Zugbildungslisten) zu liefern. Als Inhalte sind alle Fahrten für alle betroffenen Verkehrstage mit allen Behängungen zu liefern.

Lieferweg: Bis auf Weiteres an spezifische Email Adressen, die dem AN vom zuständigen RMV-Fachbereich bereitgestellt werden (z.Zt. = FZE_Import@RMV.de). Die zu liefernde Datei ist als Anhang mitzusenden. Jede E-Mail hat nur eine Datei im Anhang. Der E-Mail Titel ist identisch zum Dateinamen. Die Email kann einen beschreibenden Text der Lieferung beinhalten. Beides: Titel und Text sind zur Dokumentation der Lie- ferung vorgesehen. Es besteht die Wahl zwischen zwei möglichen

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 10 von 41

[Seite 11]

Liefervarianten (LiVa).

LiVa A.) Unter Verwendung von Verkehrstagesschlüsseln die ausschließlich vom RMV vorgegeben und dem AN zur Verfügung gestellt werden.

LiVa B.) Als tagesscharfe Lieferung für alle betroffenen Tage des Fahrplanjahres

Die Dateinamen sind wie folgt aufzubauen: PLAN_BETREIBER_LINIE_FPLJ_VERSION.fze

Dabei gilt PLAN : fester Bestandteil des Dateinamens

BETREIBER : Kürzel nach Vorgabe RMV

LINIE : Kürzel nach Vorgabe RMV

FPLJ : 4-stelliges Fahrplanjahr

VERSION : VNNN Versionskennung je Sendung des FPL-Jahres aufsteigend

Dabei: V=fester Bestandteil, NNN=dreistellige Zahl mit führender 0

.planvts.fze : Dateiendung für das Lieferformat A. ist zwingend vorgegeben

.plantag.fze : Dateiendung für das Lieferformat B. ist zwingend vorgegeben

Beispiel: PLAN_VIAS_64_2015_V003.plantag.fze

Eine Lieferdatei besteht aus einem mehrzeiligen Header und den unmittelbar nachfolgenden Datenzeilen.

Der Header besteht aus mehreren Zeilen, deren jede mit einem Schlüsselwort eingeleitet wird, das mit einem „#“ beginnt und einem „:“ endet. Dahinter steht, nach beliebig vielen Leerzeichen, der jeweilige Wert.

Vorgegebene Dateninhalte:

Bei Lieferungen nach LiVa A.) lautet die erste Headerzeile wie folgt: #INTERFACE: planvts.fze

Bei Lieferungen nach LiVa B.) lautet die erste Headerzeile wie folgt: #INTERFACE: plantag.fze

Die Bezeichnung für die Inhalte #OPERATOR und #CONTRACT des Headers werden vom RMV vorgegeben. Die Werte sind durchweg ohne Klammer anzugeben.

Tabelle 1.2: Header Importformat Kapazitätsmeldung im SPNV (PLAN)

Header für die Importdateien #INTERFACE: [plantag.fze, planvts.fze] #OPERATOR: (Betreibername) #CONTRACT: (Verkehrsvertrag). Im RMV stattdessen „Teilnetzkürzel“ #YEARMONTH: {YYYY01,..,YYYY12} * #YEARQUARTER: {YYYY01,..,YYYY04} * #YEARCALENDARWEEK: {YYYY01,..,YYYY53} * #FROM: (Von-Datum im Format DD.MM.YYYY) * #TO: (Bis-Datum im Format DD.MM.YYYY) *

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 11 von 41

[Seite 12]

Die ersten drei Headerzeilen (also #INTERFACE, #OPERATOR und #CONTRACT) müssen für den automa- tischen Import in den Dateien enthalten sein.

Eine Angabe zum Referenzzeitraum für die Vollständigkeitsprüfung muss nur enthalten sein, wenn eine Voll- ständigkeitsprüfung durchgeführt werden soll. Solange keine gegenteilige Vereinbarung besteht ist immer so zu liefern, dass eine Vollständigkeitsprüfung durchgeführt werden kann. Dann muss genau eine der folgenden Angaben zum Referenzeitraum enthalten sein. Hierbei sind, rein technisch, folgende Alternativen möglich:

• ein Monat

• ein Quartal,

• eine Kalenderwoche oder

• ein Datumsbereich

Beispiel:

#INTERFACE: plantag.fze

#OPERATOR: Deutsche Bahn AG

#CONTRACT: MDSB-I

#YEARMONTH: 201608

Für die KAPAZITÄTS PLANDATEN eines Fahrplanjahres die jährlich vor Beginn eines Fahrplanjahres an den RMV zu liefern sind, ist die Option (#FROM und #TO) zu nutzen.

Dabei ist der erste und der letzte Tag des Fahrplanjahres anzugeben.

Die anderen Optionen können ggf. unterjährig zur Lieferung abgestimmter Änderungen eine Rolle spielen.

Nachfolgend ist die Struktur der Datenzeilen beschrieben.

Die Spalte „LiVa“ beschreibt ob diese Spalte in der entsprechenden Liefervariante enthalten ist.

Bei Lieferungen gemäß der LiVa A. (Verwendung von Verkehrstagesschlüsseln) haben die Datenzeilen 13 Felder (12 Semikola) und die Datenstruktur beginnt als erstes Feld mit „Fahrtnummer“ und endet mit dem Feld „VTS“.

Bei Lieferungen gemäß der LiVa B. (tagesscharfe Lieferung) haben die Datenzeilen 11 Felder (10 Semi- kola) und die Datenstruktur beginnt als erstes Feld mit „Datum“ und endet mit dem Feld „Bemerkung“.

Die Spalte "Erf-A“ bzw. Erf-B" zeigt an, ob das jeweilige Merkmal in der fraglichen LiVa inhaltlich immer ("J") gefüllt sein muss. Bei „N“ ist der Inhalt optional – das Feld ist dann leer zu liefern.

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 12 von 41

[Seite 13]

Tabelle 1.3: Importformat Kapazitätsmeldung im SPNV (PLAN)

Der Typ DATUM ist anzugeben in der Form: TT.MM.JJJJ

Der Typ ZEIT ist anzugeben in der Form: HH:MM:SS, eine Befüllung ohne Sekunden (also HH:MM) und ohne führende Null bei den Stunden wird akzeptiert, sofern dies den Fahrplanvorgaben entspricht.

• Beispiel LiVa A : 98765;FH;FWH_2;;;08:38:00;64;can_NOH_Flirt_1x3;;;10.10.2016;31.12.2016;mo-fr

• Beispiel LiVa B: 16.05.2009;98765;FH;FWH_2;;;08:38:00;64;can_NOH_Flirt_1x3;;

Für beide Liefervarianten gilt:

Im Datenblock steht in jeder Zeile genau ein Datensatz.

Es wird nicht zwischen Groß- und Kleinschreibung unterschieden.

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 13 von 41

[Seite 14]

3.2.3. Aktuelle Daten zum Betriebsablauf

3.2.3.1. Grundsätzliches

Der AN muss für eine Echtzeitdatenbasis sorgen, die verlässliche Prognosen ermöglicht.

Die Kommunikation zwischen AG und AN erfolgt über standardisierte Schnittstellen, welche vom Verband deutscher Verkehrsunternehmen (VDV) in den Schriften der VDV-454 und VDV-453 definiert wurden. Die vom AN aktuell anzuwendenden Versionen der Schnittstellen sind in Anhang 5 und Anhang 8 definiert. Darüber hinaus sind weitere für den AN verbindliche, fachlich ergänzende Vorgaben, die mindestens zu liefernden Dienste sowie weitere Details zu den VDV-453 und VDV-454-Schnittstellen im Anhang 8 zu finden.

Um dem technischen Fortschritt zu entsprechen, hat der AN nach Aufforderung des AG nachfolgende Anpas- sungen bei den v.g. Schnittstellen vorzunehmen:

• Binnen einer Frist von einem Jahr nach Aufforderung durch den AG müssen vom AG benannte optionale Felder verbindlich geliefert werden. Die Aufforderung durch den AG erfolgt bis spätestens 2 Jahre vor Ablauf des VSV.

• Binnen einer Frist von zwei Jahren nach Aufforderung durch den AG müssen die VDV453/454-Schnittstel- len auf vom AG vorgegebene neue Version aktualisiert werden. Die Aufforderung durch den AG erfolgt bis spätestens 4 Jahre vor Ablauf des VSV.

Im BPNV ist mit maximal einer Versionsanpassung zu kalkulieren.

Im SPNV ist mit maximal zwei Versionsanpassungen zu kalkulieren.

Im Sinne der Realisierbarkeit sind Einzelvereinbarungen in Absprache mit dem Bereich Informationstechno- logie des AG zulässig.

3.2.3.2. Positionserfassung

Der AN muss eine Einrichtung zur permanenten Positionserfassung der Fahrzeuge mit Hilfe satellitengestütz- ter Systeme oder eine gleichwertige Umsetzung aufbauen und mit den damit erzeugten Daten einen Soll-Ist- Abgleich des Fahrplans mit Hilfe eines rechnergestützten Betriebsleitsystems (RBL/ ITCS) durchführen.

Folgende Kriterien sind im Zusammenhang mit der Positionserfassung zu erfüllen:

• Die Positionserfassung muss ständig erfolgen. Das heißt, dass eine Aktualisierung mindestens im Zeitin- tervall von 10 Sekunden erfolgen muss.

• Die Positionserfassung muss jederzeit möglich sein und einen Bezug zum Fahrweg haben.

• Der vollständige oder teilweise Ausfall fahrzeugexterner Systeme zur Positionserfassung (z.B. GPS-Emp- fang) muss durch eine geeignete Rückfallebene bzw. -strategie abgesichert sein. Die Ortung muss über den Wegimpuls/das Türkriterium auch bei ausbleibendem GPS-Signal (z.B. bei Abschattungen) weiterhin möglich sein.

• Die Positionserfassung muss ohne das Erfordernis von Bedienhandlungen durch das Betriebspersonal funktionieren.

3.2.3.3. Leitsystem (allgemein)

Die für die Erfüllung der Anforderungen gemäß dieses Vertrages notwendige technische Infrastruktur, z.B. ein rechnergestütztes Betriebsleitsystem (RBL/ITCS), muss das Verkehrsunternehmen einrichten. Es muss ge- währleistet sein, dass Abnahmetests von Daten oder Software unabhängig vom laufenden produktiven Be- trieb des AN durchgeführt werden können. Dazu ist ein unabhängiges, zweites System zum Test (seitens des AN) bereitzustellen auf das in gleicher Weise zugegriffen werden kann. Der Aufbau eigenständiger Systeme ist nicht zwingend erforderlich, Beteiligungen an bereits vorhandenen Systemen sind zulässig.

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 14 von 41

[Seite 15]

Im RBL/ITCS müssen mindestens folgende technische Komponenten und Funktionen realisiert werden:

• Basierend auf allen im RBL/ITCS vorhandenen Informationen müssen Prognosen sofort bzw. nach Über- schreitung der jeweils vorgegebenen Hysterese für alle Halte und noch nicht stattgefundene Ereignisse (Abfahrt und Ankunft) erstellt und kommuniziert werden.

• Bei der Berechnung der Prognosen müssen insbesondere folgende Einflussgrößen berücksichtigt werden:

„Beschleunigung“ (z.B. bei infolge Fahrzeugstörung verminderter Traktionsleistung)

„Geschwindigkeit“ (z.B. bei reduzierter Strecken- oder Fahrzeughöchstgeschwindigkeit)

„Haltestellenaufenthaltszeit“ (z.B. bei operativer Kürzung von längeren Verkehrshalten bis zur Min- destaufenthaltszeit, bei dispositiv festgelegtem Warten auf Anschlussreisende)

„betriebliche Haltezeiten“ (z.B. infolge dispositiver Änderungen bei Zugfolge, Zugkreuzung)

dispositive Eingriffe und deren Auswirkungen (z.B. Kurzwenden, Änderung der Umlaufverknüpfung)

• Bei fehlender Anmeldung einer Fahrt am Leitsystem des AN muss die Prognose für alle noch nicht statt- gefundenen Ereignisse (Abfahrt und Ankunft) gemäß der jeweils definierten Hysterese erhöht bzw. zurück- genommen werden. Abfahrtsverzögerungen an der Startstation sind unmittelbar darzustellen. Nach spä- testens fünf Minuten hat der AN über den Grund der Verzögerungen via Leitsystem zu informieren. Ins- besondere darf zu keinem Zeitpunkt eine pünktliche Prognose für aktuelle Fahrten beauskunftet werden, die nicht der Kontrolle des Leitsystems unterliegen.

• Das RBL/ITCS muss über eine Selektionsfunktion von mehreren Fahrten das schnelle Setzen jeglicher Geschäftsvorfälle (insbesondere manuelle Prognosen/dispositive Fahrtzeitänderungen, Fahrt-/Haltaus- fälle, Zusatzhalte, Verspätungsbegründungen, Qualitätsabweichungen) ermöglichen. Die Selektion der betroffenen Fahrten muss mindestens nach Linie (mit Richtung), Fahrt-/Zugnummernschema, Halten und Zeit möglich sein.

• Prognosen/Geschäftsvorfälle müssen auf Folgefahrten (Umlauf) vererbt werden, einschließlich Berück- sichtigung von Wendezeiten und automatischen Setzens der Verspätungsbegründung „Verspätung aus vorheriger Fahrt“, soweit keine andere Codierung vorgenommen wurde. Verspätungen aus einer vorheri- gen Fahrt sind spätestens zur Fahrtanmeldung der Folgefahrt für diese zu übernehmen.

• Ein schnelles Anlegen von Zusatzfahrten/Ersatzfahrten (einschließlich Busnotverkehr bei Fahrwegunter- brechungen) muss ebenso vom RBL/ITCS unterstützt und vorgenommen werden.

Soweit möglich, sind vom AN eigenständig und rechtzeitig vor der Testphase mit dem AG folgende Punkte zu testen und erkannte Mängel zu beheben:

• korrekte Positionserfassung der Fahrzeuge und entsprechende Darstellung in der Echtzeitinformation (korrekter Soll-Ist-Abgleich der Fahrzeugpositionen und daraus möglichst früh abgeleitete sowie perma- nent aktualisierte Ankunfts- und Abfahrtsprognosen)

• durchgängige Konsistenz/Durchgängigkeit der Echtzeitdaten (formal und inhaltlich) und Übertragung der Daten in andere Systeme und deren korrekte Darstellung/Verarbeitung dort.

Die technische Anbindung des RBL/ITCS über das Internet (https, http) an die Datendrehscheibe des AG muss vom AN fristgerecht vor Betriebsaufnahme umgesetzt sein und die Echtzeitdatenlieferung aus dem RBL/ITCS geliefert werden können. Diese Daten bilden die Grundlage für den gemeinsamen Abnahmetest des RBLs/ITCS zwischen AN und AG. Ein erfolgreich absolvierter Test ist die Voraussetzung für die Über- nahme der Daten in die produktive Fahrplanauskunft des AG. Die Testinhalte können beim AG im Vorfeld abgefragt werden. Bei Versionsänderungen der VDV-Schrift 453/454 werden die Testinhalte aktualisiert und anschließend wird mit dem AN ein weiterer Abnahmetest durchgeführt.

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 15 von 41

[Seite 16]

3.2.3.3.1. Leitsystemzusatz für Schienenpersonennahverkehr (SPNV)

Soweit nicht anders geregelt, muss sich der AN an die Datensysteme der im Rahmen des vertragsgegen- ständlichen Streckennetzes tätigen Eisenbahninfrastrukturbetreiber (EIU) über eine Datenschnittstelle bzw. externen Verteiler anschließen. Hierüber sind die Zuginformationen der vertragsgegenständlichen Leistung (u.a. UIC-Datensatz Telegramm 2102, 2105, 2154, inhaltlich filterlos, d.h. alle Informationen in vollem Um- fang) zu beziehen und im eigenen ITCS zu verarbeiten. Zuginformationen sind auch für Durchfahrten, auch auf Umleitungsstrecken, zu beziehen. Soweit das EIU die Daten auch über die technischen Spezifikationen für die Interoperabilität der Teilsysteme Telematikanwendung für den Güter- und Personenverkehr (TAF/TAP TSI) zur Verfügung stellt, ist die Anbindung über diese Schnittstelle vorzunehmen. Die Kosten sind durch den AN zu tragen. Der AN muss gemäß der Abgaberegelung des jeweiligen EIU das schriftliche Einverständnis aller angrenzenden Eisenbahnverkehrsunternehmen für die Nutzung ihrer Daten einholen.

Im ITCS müssen mindestens folgende technische Komponenten und Funktionen realisiert werden:

• Eine aus Fahrzeugdaten ermittelte Fahrplanlage einer Zugfahrt muss stetig gegen Zuglaufmeldungen aus der Datenschnittstelle bzw. dem externen Verteiler des EIU validiert werden. Bei Differenzen muss Prog- nosehandlungsbedarf abgeleitet werden.

• Das nicht erfolgte Passieren eines ggf. festgelegten Messpunktes muss (wenn keine konkreten gegentei- ligen Informationen vorliegen) als Erhöhung der Prognose für alle noch nicht stattgefundenen Ereignisse (Abfahrt und Ankunft) gewertet und kommuniziert werden. Nach spätestens fünf Minuten sind die Dispo- nenten in der Betriebsleitzentrale und der Informationsmanager durch das ITCS über den außerplanmä- ßigen Stillstand des Zuges zu informieren. Sie haben den Grund für den Halt zu klären und unverzüglich eine entsprechende Begründung für die Fahrgäste ins Fahrgastinformationssystem einzustellen.

3.2.3.4. Technische Schnittstellen

3.2.3.4.1. Anwendungsfall „Fahrplanauskunft“

Die aktuellen Verkehrsdaten (Dienst AUS gemäß VDV454) sind vom AN gemäß den in VDV454-Schrift (je- weils in der aktuellen Version, , vgl. Ziffer 3.2.3.1) definierten Formaten und Prozeduren zu liefern. Dabei sind vom AN auf Anforderung des AG alle optionalen Felder der vorgenannten VDV-Schnittstellen inhaltlich zu befüllen, sofern nicht in Anhang 8 anders geregelt.

3.2.3.4.2. Anwendungsfall „Fahrgastinformation an Stationen bzw. im Fahrzeug“

Soweit in Anhang 8 nicht anders geregelt, sind die tagesaktuellen Sollfahrpläne (Dienst REF-DFI gemäß VDV- Schrift 453) und die aktuellen Verkehrsdaten (Dienst DFI gemäß VDV453) gemäß den in VDV-Schrift 453 (jeweils in der aktuellen Version, vgl. Ziffer 3.2.3.1) definierten Formaten und Prozeduren ab Betriebsauf- nahme zu liefern. Dabei sind vom AN auf Anforderung des AG alle optionalen Felder der vorgenannten VDV- Schnittstellen inhaltlich zu befüllen.

3.2.3.4.3. Anwendungsfall „Anschlussmanagement“

Aus dem ITCS ist eine Kommunikationsmöglichkeit zu anderen RBL/ITCS-Systemen im Bediengebiet zum Zwecke der Anschlusssicherung (automatische Voranmeldung definierter verspäteter Zubringer) und Fahr- gastinformation mittels des Dienstes ANS gemäß VDV-Schrift 453 (jeweils in der aktuellen Version) ein- schließlich Rückkanal zu realisieren.

Im Falle des Anschlusszubringers sind insbesondere die Datensätze „Ausfall“, „Haltepositionsänderung“ und „wartet bis“ von den abbringenden ÖPNV/SPNV-Unternehmen zu verarbeiten.

Im Falle des Anschlussabbringers ist insbesondere die eigene Wartebereitschaft an den Anschlusszubringer rechtzeitig zu übermitteln.

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 16 von 41

[Seite 17]

Zur Vermeidung einer Vielzahl von Datenschnittstellen zu den einzelnen RBL/ITCS-Systemen innerhalb des Bediengebietes, ist dies über die jeweils zentralen Anschlussbroker (ebenfalls VDV-Schrift 453 und VDV- Schrift 454) des AG zu realisieren.

3.2.3.4.4. Visualisierung von Fahrzeugpositionen

Soweit in Anhang 8 nicht anders geregelt, sind die aktuellen Verkehrsdaten (Dienst VIS gemäß VDV-Schrift 453) gemäß den in VDV-Schrift 453 (jeweils in der aktuellen Version, vgl. Ziffer 3.2.3.1) definierten Formaten und Prozeduren zu liefern.

3.2.3.5. Zuzuliefernde Daten und Fristen

3.2.3.5.1. Sachlicher Umfang

Abweichungen vom Sollfahrplan umfassen mindestens folgende Aspekte:

• Fahrtausfall/Teilausfall

• kurzfristige Fahrplanänderungen

• zusätzliche Zuglaufdaten (*nur für SPNV)

• Zusatzfahrt

• Änderungen des Fahrzeugtyps/der Ausstattung (insbesondere relevant für Barrierefreiheit und Fahrgast- information)

• Änderungen des Fahrwegs/Haltestellensperrungen

• außerplanmäßiger Halt

• Änderungen von Gleisen/Steigen/Bereichen (insbesondere für Kuppeln und Flügeln von Bedeutung)

• Änderungen von Attributen (z.B. Einsteigeverbot, Fahrradmitnahme)

• Informationen zur Auslastung

• Informationen über das Abwarten von Anschlüssen bzw. Anschlussbruch

• Schienenersatzverkehr mit Bussen und soweit möglich im Busnotverkehr

Diese Daten, sind qualitätsgesichert und vollständig zu liefern, d.h. die Fahrplandaten müssen alle zur Fahr- gastbeförderung freigegebenen Fahrten und alle von diesen bedienten bzw. durchfahrenen Verkehrsstatio- nen enthalten.

Fahrtanmeldungen und Fahrtzeitprognosen für geflügelte Fahrten sind entsprechend der gemeldeten Fahr- plandaten zu liefern:

• Werden zwei separate Fahrten im Fahrplan gemeldet, so sind pro Fahrt auch die Daten zu melden. Hierbei sollten beide Fahrten für den gekoppelten Fahrtabschnitt die gleichen Prognosedaten aufweisen.

• Werden die im Rahmen des Flügelungskonzepts gemeinsam geführten Fahrten als eine Fahrt im Fahrplan gemeldet und erfolgt eine zweite Fahrt erst ab der Teilung in die Flügelfahrten, so muss die Verspätung auch für die am Fahrtteilungshalt neu beginnende Fahrt mit deren Fahrtanmeldung, spätestens 15 Minuten vor der geplanten Abfahrt am Fahrtteilungshalt automatisch übernommen werden. Beim Vereinigen der Fahrtteile muss für den gemeinsam bedienten Laufwegabschnitt ab dem Vereinigungsbahnhof die höchste Verspätung der bis dahin eigenständigen Fahrten, ggf. zu- bzw. abzüglich dispositiver Haltezeitzu- bzw. - abschläge im Zusammenhang mit dem Vereinigen der Fahrtteile übernommen werden.

3.2.3.5.2. Metadaten

Der AN ist dafür verantwortlich, dass die zur Verfügung gestellten Daten und Informationen eindeutig aufei- nander abbildbar sind. Dies betrifft insbesondere die Abbildung des tagesaktuellen Sollfahrplans auf den Jah- resfahrplan sowie die Abbildung der Echtzeitdaten auf den tagesaktuellen Sollfahrplan.

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 17 von 41

[Seite 18]

Die mit den Prognosedaten gelieferten Fahrten müssen auf Basis der gelieferten mastscharfen Fahrplanda- ten beruhen. Abweichungen dazu sind durch die Systeme anzuzeigen. Zusatzfahrten sind entsprechend zu kennzeichnen. Für die Abbildung der in den Echtzeitdaten verwendeten Haltepunkte und Linien auf den Soll- fahrplan muss vom AN eine laufend aktuell gehaltene Metadatenliste bereitgestellt werden.

Der AN hat eine Umschlüsselung von betrieblichen Gleis-/Steigbezeichnungen in Kundengleise/-steige vor- zunehmen. Die dazu erforderlichen Metadaten sind laufend aktuell zu halten. Für den SPNV sind diese Daten mit den jeweils beteiligten EIU abzustimmen.

3.2.3.5.3. Istdaten

Istdaten geben zum Zeitpunkt der Abfrage die aktuelle Position des Fahrzeugs der jeweiligen Fahrt wieder. Insbesondere die tatsächlich realisierte Ankunfts- und Abfahrtszeit eines Fahrzeugs an einer Verkehrsstation stellt für die Fahrgastinformation ein fahrgastrelevantes Informationsmerkmal dar. Der AN muss daher die haltestellenspezifischen Istdaten sowie die Position der eingesetzten Fahrzeuge zwischen den Haltestellen für die Fahrgastinformation bereitstellen.

Mindestanforderungen Istdaten:

• Datenquantität: aktuelle Ankunfts- und Abfahrts- bzw. Durchfahrtszeit aller Fahrten an allen Verkehrsstati- onen des hier ausgeschriebenen Streckennetzes mit Halt und Durchfahrt

• Datenqualität: Die Übergabe muss unverzüglich, sobald die Daten erzeugt sind, erfolgen. Daten dürfen maximal eine Minute alt sein (Erfassung, Berechnung, Übertragung); Zielwert sind 10 Sekunden

3.2.3.5.4. Prognosedaten

Die gemäß den Anforderungen im Kapitel Leitsystem prognostizierten Ankunfts- und Abfahrtszeiten sind für alle im Rahmen der hier ausgeschriebenen Verkehrsleistungen zu bedienenden Haltestellen zu ermitteln und zu übertragen.

Mindestanforderungen Prognosedaten:

• Datenquantität: Diese Prognosedaten sind auf der Basis einer technischen Prognose zu Beginn der Vor- schauzeit bereitzustellen.

Die dispositiven Maßnahmen sind vom RBL/ITCS, unabhängig von der Vorschauzeit (siehe An- hang 8), so früh wie möglich zu übermitteln.

• Datengenauigkeit:

Sämtliche Zeitangaben zu den Fahrtereignissen sind im Referenz- und Prozessdatendienst mindes- tens minutengenau (Sekunde:00) zu liefern und zu berechnen, soweit die Hysterese während der Vertragslaufzeit durch den AG nicht auf einen Wert kleiner 60 Sekunden festgelegt wird (in diesem Fall sind sekundengenaue Prognosen zu übermitteln).

Abweichend davon sind Zeitangaben für Istdaten (IstAbfahrtPrognose mit IstAbfahrtPrognoseStatus Real bzw. IstAnkunftPrognose mit IstAnkunftPrognoseStatus Real) stets sekundengenau zu liefern. Zeitangaben erfolgen unter Angabe der Abweichung zu UTC, z.B. 2018-09-05T07:29:52+02:00.

• Datenqualität:

Daten dürfen maximal eine Minute alt sein (Erfassung, Berechnung, Übertragung); Zielwert sind 10 Sekunden

Die Verfügbarkeit der Prognosedaten darf 99,0% bei der Generierung und Absendung der Datente- legramme nicht unterschreiten. Der Prozentsatz bezieht sich auf alle planmäßigen Verkehrshalte und gilt für die Sendung bis zum Zeitpunkt der tatsächlichen Ankunft bzw. Abfahrt an der jeweiligen Verkehrsstation.

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 18 von 41

[Seite 19]

Abb. 1: RMV integriertes Daten-Management: Überblick: Qualitätsdatenfluss und Prognosedatenfluss inkl. Anschlusssicherung

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 19 von 41

[Seite 20]

3.3. Qualitätsdaten BPNV

3.3.1. Automatische Pünktlichkeitserfassung im BPNV

Bei Einsatz von Rechner-gestützten Betriebsleitsystemen (RBL/ITCS) sind die Daten für o.g. Zwecke durch die ständige Fahrzeugverfolgung vorhanden.

3.3.1.1. Zielstellung

Für die automatische Protokollierung der Einsatz- und Fahrtzeiten der Busse im Liniennetz des öffentlichen Personennahverkehrs wird ein System gefordert, das Fahrzeugtyp- und herstellerunabhängig aufgebaut ist und sich im vorhandenen Wagenbestand durch Nachrüstung rückwirkungsfrei in die Fahrzeugsysteme integ- rieren lässt. Das Pünktlichkeitserfassungssystem muss ausreichend präzise alle notwendigen Zeit-, Weg- und Ortsdaten liefern, so dass ein EDV-Hintergrundsystem die Fahrtverlaufsanalyse in aussagekräftiger Form dem Er- und Besteller bereitstellen kann.

3.3.1.2. Systembeschreibung

Zur Ortung ist eine GPS-Empfangseinrichtung einzusetzen, die durch logische Ortung ergänzt werden kann. Ortungsverfahren, die von der Genauigkeit gleich oder besser als GPS sind, werden ebenfalls akzeptiert. Eine alleinige logische Ortung wird nicht akzeptiert.

Das System muss folgende Anforderungen erfüllen:

• Aufrüstung der Fahrzeuge mit einem Bordrechner (ggf. inklusive GPS-Einheit)

• Fahrzeugortung

• Fahrplan-Soll-IST-Vergleich

• Standortdatenübertragung

• Informationsumfang Fahrzeug

• Fahrzeugbordrechner

• Wegimpuls vom Tachografen für „steht“ / „fährt“

• Türfreigabe

• ggf. GPS-Position mit Datum und Uhrzeit

• Schnittstellen/Datenformate

• hohe Betriebs- und Manipulationssicherheit und Kontrollierbarkeit ist zu gewährleisten

• Messung, Dateneingabe, Datenabgleich (inkl. Plausibilitätsprüfung)

• System muss unabhängig vom Fahrzeugtyp einsetzbar sein

• Volle Restartfähigkeit des Rechners bei Störungen jeglicher Art (manuell und automatisch)

• Genauigkeit der Positionsmessung besser +/- 15 m

• Automatische und standardisierte Übernahme der Daten in die RMV-Datenbank

• manipulationsfreie wöchentliche Lieferung der Pünktlichkeitsdaten aller Fahrten an allen Haltestellen durch Import in die webbasierte Qualitätsdatenbank.

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 20 von 41

[Seite 21]

3.3.2. Pünktlichkeitsdaten im BPNV

Der AN meldet die Ankunftspünktlichkeit aller Fahrten auf den von ihm bedienten Linien. Die Erfassung der Pünktlichkeit hat automatisch und an allen Haltestellen zu erfolgen.

Der AN kann die entsprechenden Daten entweder durch den Betreiber der Leitstelle oder des RBL/ITCS zur Verfügung stellen lassen oder über ein geeignetes Verfahren (vgl. Ziffer 3.3.1) selbst erfassen. Zur automati- schen und standardisierten Übernahme der Daten in die RMV-Datenbank hat der AN die Daten durch Import in die webbasierte Qualitatsdatenbank nach dem folgenden Verfahren dem AG zu liefern.

Dem AN wird ein Handbuch für die webbasierte Qualitatsdatenbank online zur Verfügung gestellt.

Verfahrensweg: Datenimport von ASCII-Dateien

(1) Die Pünktlichkeitsdaten gemäß den Vertragsunterlagen sind vom AN als ASCII-Datei mit Trennzeichen, je Zeile genau ein Datensatz, also als Datei im „.csv“-Format, allerdings mit definierten Inhalten, in die webbasierte Qualitatsdatenbank im folgenden Format zu importieren: • Die Pünktlichkeitsdaten sind in der ersten Zeile mit einer Headerzeile zu liefern. Als Headerbezeich- nung ist der Feldname zu verwenden. • Die Pünktlichkeitsdateien haben die Extension „.csv“. • Der Name der Pünktlichkeitsdateien setzt sich wie folgt zusammen: „Pkt_Linie[Linien-Nr. bzw. Kürzel Linienbündel-Name]_KW[Kalenderwochen-Nr.].csv“, z.B. „Pkt_Linie20_KW09.csv“. Das Kürzel für den Linienbündel-Name ist mit dem AG vorher abzustimmen. Die Kalenderwoche im Dateinamen ist immer zweistellig, also z.T. mit führender Null zu liefern. Zur Definition der „Kalenderwoche“ siehe Kapitel 4 → Glossar. • Es wird nicht zwischen Groß- und Kleinschreibung unterschieden. • Jeder korrekte Datensatz muss genau 15 Semikola enthalten. (2) Beispiele: L;AN;12345;4787;;15.08.2014;15.08.2014;15;20;23;5;07:45:00;04711;JFK;00815;LAX N;AN;12346;4576;;14.08.2014;15.08.2014;10;15;17;2;13:10:00;04711;JFK;00815;LAX (3) Der AG behält sich vor, vom AN die Protokolldateien der automatischen Pünktlichkeitserfassung inner- halb eines Kalenderjahres anzufordern. (4) Erläuterungen zu den Kodierungen der Verspätungsursachen:

Tabelle 2.1: Kodierungen der Verspätungsursachen

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 21 von 41

[Seite 22]

Tabelle 2.2: Datenformat Meldung der Pünktlichkeitsdaten im BPNV

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 22 von 41

[Seite 23]

3.3.3. Ausfall oder Teilausfalldaten / Einsatz Fahrzeuge mit abweichender Antriebsart

(1) Die Ausfalldaten und der Einsatz von Fahrzeugen mit abweichender Antriebsart sind vom AN als ASCII- Datei mit Trennzeichen, je Zeile genau ein Datensatz, also als Datei im „.csv“-Format selbständig und fristgerecht in die webbasierte Qualitätsdatenbank des RMV zu importieren, allerdings mit definierten Inhalten. Bei Lieferung als ASCII-Datei hat dies im folgenden Format zu erfolgen:

1. Die Ausfalldaten sind in der ersten Zeile mit einer Headerzeile zu liefern. Als Headerbezeichnung ist der Feldname zu verwenden.

2. Die Ausfalldateien haben die Extension „.csv“.

3. Es wird nicht zwischen Groß- und Kleinschreibung unterschieden.

4. Jeder korrekte Datensatz muss genau 20 Semikola enthalten.

5. Zum Aufbau des Dateinamens siehe Abschnitt 2.3

(2) Beispiel Ausfallmeldung:

L;AN;;123;06:00:00;07:00:00;111;01.08.2023;01.08.2023;01.08.2023;01.08.2023;04711;ADorf-Rat- haus;00815;XDorf-Kirche;0;0;102;1;50.000;00:01:15

Beispiele für Bündel mit gemischten Antriebsarten

Ausfall E-Bus:

L;AN;E;123;06:00:00;07:00:00;111;01.08.2023;01.08.2023;01.08.2023;01.08.2023;04711;ADorf-Rat- haus;00815;XDorf-Kirche;0;0;102;1;50.000;00:01:15

Ersatz E-Bus durch Dieselbus

L;AN;DE;123;06:00:00;07:00:00;111;01.08.2023;01.08.2023;01.08.2023;01.08.2023;04711;ADorf-Rat- haus;00815;XDorf-Kirche;1;0;102;1;50.000;00:01:15

(3) Die Ausfalldaten werden gemäß RMV-Standardcodierung (dreistellig, gemäß Tabelle 3.1) geliefert. Der Wertebereich geht von 100 bis 199.

Ausfallursachen gemäß RMV-Standardkodierung sind wie folgt kodiert:

Tabelle 3.1: Kodierungen der Ausfallursachen

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 23 von 41

[Seite 24]

(4) Besonderheit bei Bündeln mit Fahrzeugen unterschiedlicher Antriebsarten

Ausfallmeldung und Einsatz von Fahrzeugen mit abweichender Antriebsart:

Eingabe Spalte C:

Ausfälle:

E=Elektro

D=Diesel

Bei Fahrzeugeinsatz mit einer abweichenden Antriebsart:

ED=Elektro für Diesel

DE=Diesel für Elektro

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 24 von 41

[Seite 25]

Tabelle 3.2: Datenformat Meldung der Ausfall- oder Teilausfalldaten / Einsatz Fahrzeuge mit abweichender Antriebsart

1 Relevanz bei Bündeln mit Fahrzeugen unterschiedlicher Antriebsarten

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 25 von 41

[Seite 26]

3.4. Qualitätsdaten SPNV

3.4.1. Pünktlichkeitsdaten im SPNV

Der AN meldet die Ankunftspünktlichkeit aller Fahrten an allen Stationen auf den von ihm bedienten Linien. Die Erfassung der Pünktlichkeit hat an allen Stationen automatisch zu erfolgen. Der AN kann die entspre- chenden Daten entweder bei der DB InfraGO beschaffen oder über ein geeignetes Verfahren (z.B. GPS) selbst erfassen.

Der Import der Pünktlichkeitsdaten in die webbasierte Qualitätsdatenbank des RMV hat fristgerecht und selb- ständig durch den AN zu erfolgen. Als Datenformat für die Meldung bzw. den Import von Pünktlichkeitsdaten findet das PAD-Datenformat in Verbindung mit den zugehörigen Verspätungsursachen im SZU-Datenformat (beides auf Grundlage der Datenformatsdefinitionen von DB InfraGO2) gemäß nachfolgender Tabellen / De- finitionen Anwendung. Grundsätzlich bilden PAD-Datei (Pünktlichkeitsdaten) und zugehörige SZU-Datei (Ver- spätungsursachen) eine logische Einheit. Der Import unterliegt den entsprechenden Fristenregelungen. Eine Datenlieferung gilt grundsätzlich erst nach erfolgreichem Import in die webbasierte Qualitätsdatenbank als erfolgt.

3.4.1.1. Pünktlichkeitsdaten im SPNV als PAD Lieferung

Die Pünktlichkeitsdaten im SPNV sind in der ersten Zeile mit einer Headerzeile zu liefern. Als Headerbezeich- nung ist der Feldname zu verwenden.

In der PAD-Auswertung müssen folgende Attribute enthalten sein:

Tabelle 4.1: Attribute in PAD-Datenlieferung (Pünktlichkeitsdaten) im SPNV

2 Als Datenfeldtrennzeichen finden hier TABs Verwendung, nicht Semikola.

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 26 von 41

[Seite 27]

3.4.1.2. Verspätungsursachen im SPNV ergänzend zur PAD Pünktlichkeitslieferung

Die Verspätungsursachen im SPNV sind in der ersten Zeile mit einer Headerzeile zu liefern.

Als Headerbezeichnung ist der Feldname zu verwenden.

In der SZU-Auswertung müssen folgende Attribute enthalten sein:

Tabelle 4.2: Attribute in SZU-Datenlieferung (Verspätungsursachen) im SPNV

Hochverspätungen müssen als NC 99 im Feld „VUZN“ gekennzeichnet werden. Hierzu ist es zusätzlich er- forderlich die jeweilige Primärursache bei „VU“ einzutragen.

3.4.2. Ausfalldaten, Ersatzfahrzeuge, BNV bzw. SEV im SPNV

(1) Die Ausfalldaten und der Einsatz von Ersatzfahrzeugen bzw. die Einrichtung von BNV oder SEV sind vom AN selbständig und fristgerecht in die webbasierte Qualitätsdatenbank des RMV zu importieren. Als Datenformat findet die Definition gemäß Tabelle 5.1 Anwendung.

(2) Die Daten sind in der ersten Zeile mit einer Headerzeile zu liefern. Als Headerbezeichnung ist der Feld- name zu verwenden.

(3) Zum Aufbau des Dateinamens siehe Abschnitt 2.3

(4) Die Ausfalldateien haben die Extension „.csv“.

(5) Die Inhalte der alphanumerischen Felder dürfen keine doppelten Anführungszeichen ASCII Zeichen 34 (dezimal) enthalten, weder als Teil der Wertes noch als (gedachte) Feldbegrenzungszeichen. Falls der Wert eines Feldes doppelte Anführungszeichen enthält, sind diese in der Lieferung durch einfache An- führungszeichen zu ersetzen. Als einfaches Anführungszeichen ist das ASCII Zeichen 39 (dezimal) zu verstehen.

(6) Für jede ausgefallene Fahrt ist genau 1 Datensatz zu liefern.

(7) Die Lieferung hinsichtlich der Inhalte erfolgt in UTF-8 Kodierung (mit BOM).

6. Es wird nicht zwischen Groß- und Kleinschreibung unterschieden.

7. Jeder korrekte Datensatz muss genau 23 Semikola enthalten.

(8) Entfällt.

(9) Beispiel (mit DB-Ausfallursachen):

L;AN;RE;RE30;08:22:15;09:24:16;005464;24.01.2009;24.01.2009;24.01.2009;24.01.2009;04711; Bahnhof-A-Stadt;00815;Bahnhof-Z-hausen;0;0;23;1;50,0;00:01:02;K1;RMV;Text

(10) Die Ausfallursachen werden gemäß DB-Standard kodiert (numerisch, maximal zweistellig, Wertebereich von 0 bis 99).

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 27 von 41

[Seite 28]

(11) Alle 24 Felder sind für alle Datensätze Pflichtfelder und mit entprechenden Inhalten zu liefern.

(12) Hinweis zu den Feldern „Haltepunkt_ID_Von“ und „Haltepunkt_ID_Bis“:

Es ist der Hinweis auf die Einführung der globalen HST-ID unter „Haltestellen-Identifikationsmerkmale“ im Abschnitt 3.2.1.1.1 zu beachten!

(13) Hinweis zu den Feldern „Haltepunkt_BEZ_Von“ und „Haltepunkt_BEZ_Bis“:

Nachfolgend zwei Beispiele:

a. RMV Haltestellen Nummer 4101: Die im SPNV zu verwendende DS-100 (bzw. RL-100) Bezeichnung lautet „FLB“. Der Langname (da kein Bushalt, nur im BNV/SEV) gemäß RMV Bezeichnung lautet: „Hofheim am Taunus-Lorsbach Bahnhof“.

b. RMV Haltestellen Nummer 4222: Der Langname gemäß RMV Bezeichnung lautet (reiner Bus- halt): „Kelkheim (Taunus)-Fischbach Taunusstraße“. (14) Hinweis zum Feld „AT“: Entsprechend dem Feld "AT" ist nur der Kilometer- und Fahrplanstundenanteil des jeweiligen Aufga- benträgers am gemeldeten Ausfall einzutragen. Betrifft ein Ausfall das Gebiet mehrerer Aufgabenträ- ger, ist somit für jeden betroffenen Aufgabenträger pro Ausfall ein eigener Datensatz zu erzeugen.

(15) Hinweis zu den Feldern „Fahrplandatum_Von“, „Fahrplandatum_Bis“, „Kalenderdatum_Von“, „Kalen- derdatum_Bis“ und „Uhrzeit_Bis“: Bei einem Fahrtausfall über Mitternacht bleibt „Fahrplandatum_Von“, „Fahrplandatum_Bis“ und Kalen- derdatum_Von“ gleich. Das Kalenderdatum_Bis“ beinhaltet den folgenden Tag. In diesem Zusammen- hang ist zu beachten, dass „Uhrzeit_Bis“ nicht gößer als 23:59:59 sein darf.

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 28 von 41

[Seite 29]

Tabelle 5.1: Datenformat Meldung der Ausfall- oder Teilausfalldaten / Ersatzfahrzeuge / BNV oder SEV im SPNV

3 Hierunter sind auch beispielsweise geplante Änderungen am Fahrplan (z.B. aufgrund von Personalmangel) oder dauerhafte Unterbesetzung der Stellwerke zu verstehen. 4 Ggf. ersetzt durch BNV / SEV oder Ersatzfahrzeuge (vgl. Feldname „Ersatz“) 5 Siehe Fußnote 4

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 29 von 41

[Seite 30]

3.4.3. Kapazitätsmeldung im SPNV (IST)

Zu melden sind alle Fahrten mit einer abweichenden Kapazität.. Fahrtausfälle sind hierbei NICHT als Kapa- zitätsmeldung, sondern als Ausfalldaten (s.o.) zu melden.

(1) Die Kapazitätsabweichungen sind vom AN selbständig und fristgerecht in die webbasierte Qualitätsda- tenbank des RMV zu importieren. Als Datenformat findet die Definition gemäß Tabelle 5.3 Anwendung.

(2) Die Daten sind in der ersten Zeile mit einer Headerzeile zu liefern. Als Headerbezeichnung ist der Feld- name zu verwenden.

(3) Zum Aufbau des Dateinamens siehe Abschnitt 2.3

(4) Die Dateien zur Kapazitätsabweichung haben die Extension „.csv“.

(5) Die Inhalte der alphanumerischen Felder dürfen keine doppelten Anführungszeichen ASCII Zeichen 34 (dezimal) enthalten, weder als Teil der Wertes noch als (gedachte) Feldbegrenzungszeichen. Falls der Wert eines Feldes doppelte Anführungszeichen enthält, sind diese in der Lieferung durch einfache An- führungszeichen zu ersetzen. Als einfaches Anführungszeichen ist das ASCII Zeichen 39 (dezimal) zu verstehen.

(6) Für jede Kapazitätsabweichung ist genau 1 Datensatz zu liefern.

(7) Die Lieferung hinsichtlich der Inhalte erfolgt in UTF-8 Kodierung (mit BOM).

8. Es wird nicht zwischen Groß- und Kleinschreibung unterschieden.

9. Jeder korrekte Datensatz muss genau 15 Semikola enthalten.

(8) Beispiel:

01.11.2024;15303;FF;RM;FF;FQZW;05:06:00;XXX;0;Text;600;REXX;K5;800;RMV;100,00

(9) Alle 16 Felder sind für alle Datensätze Pflichtfelder und mit entprechenden Inhalten zu liefern.

(10) Hinweis zu den Feldern „Haltepunkt_Ziel_Von“, „Haltepunkt_Ziel_Bis“ „Haltepunkt_BEZ_Von“ und „Hal- tepunkt_BEZ_Bis“:

Nachfolgend zwei Beispiele:

a. RMV Haltestellen Nummer 4101: Die im SPNV zu verwendende DS-100 (bzw. RL-100) Bezeichnung lautet „FLB“. Der Langname (da kein Bushalt, nur im BNV/SEV) gemäß RMV Bezeichnung lautet: „Hofheim am Taunus-Lorsbach Bahnhof“.

b. RMV Haltestellen Nummer 4222: Der Langname gemäß RMV Bezeichnung lautet (reiner Bus- halt): „Kelkheim (Taunus)-Fischbach Taunusstraße“. (11) Hinweis zum Feld „AT“: Entsprechend dem Feld "AT" ist nur der Kilometeranteil des jeweiligen Aufgabenträgers der gemelde- ten Kapazitätsabweichung einzutragen. Betrifft eine Kapazitätsabweichung das Gebiet mehrerer Aufga- benträger, ist somit für jeden betroffenen Aufgabenträger pro Kapazitätsabweichung ein eigener Daten- satz zu erzeugen.

Die gültigen Abkürzungen für den Bereich AT sind der Tabelle in Punkt 3.4.2 Absatz 14 zu entnehmen.

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 30 von 41

[Seite 31]

Tabelle 5.2: Importformat Kapazitätsmeldung im SPNV (IST)

3.5. Zähldaten der automatischen Fahrgastzählung (AFZS) im SPNV

3.5.1. Einleitung

Dieses Kapitel beschreibt die technische Spezifikation der AFZS-Datenbereitstellung (Datenformate, Paket- /Ablagekonventionen, Protokoll- und Vollständigkeitsinformationen) zur Nutzung in Auswertungs-, Hochrech- nungs- und Qualitätssicherungssystemen des RMV bzw. seiner Dienstleister.

6Zum Feld „Behängung / Fahrzeugverband“: In diesem Feld kann entweder ein Kürzel für den tatsächlich eingesetzten Fahrzeugverband enthalten sein oder alternativ eine Komma-separierte Liste der im Verband fahrenden Fahrzeugtypen, z. B. "A,B,C,A". Dabei sind mehr- fach identisch vorkommende Fahrzeuge jeweils einzeln aufzuzählen (wie im Bsp. für A). Die Reihenfolge (also die konkrete Behängungssequenz) spielt dabei keine Rolle. Die Liste „A,B,C,A“ ist also gleichwertig zur Liste „A,A,C,B“. Es ist zu beachten, dass in der Liste keine Semikola verwendet werden. Die Wahl, welcher Inhalt geliefert wird (Verbands- kürzel oder FZ-Typ-Liste), steht für jeden Datensatz frei. Sowohl Kürzel als auch FZ-Typen müssen zwingend aus einer vom AG bereit- gestellten Liste stammen.

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 31 von 41

[Seite 32]

3.5.2. Normative Grundlagen und Vorrang

(1) Für Struktur, Inhalte und Schemas der AFZS-Rohdaten gelten vorrangig die jeweils anwendbaren Spe- zifikationen der VDV-Schrift 457, insbesondere die Rohdatenschnittstelle VDV 457-2.

(2) Ergänzend regelt dieses Datenhandbuch ausschließlich die Liefer- und Austauschkonventionen (z. B. Paketstruktur, Dateibenennung, eindeutige Lieferkennung, Vollständigkeitsnachweise/Manifest) sowie Protokoll-/Statusinformationen, soweit diese nicht Bestandteil des jeweiligen VDV-Formats sind.

(3) Bei Widersprüchen gilt: VDV für Datenschema/-inhalte, RMV-Datenhandbuch für Übertragungs-/Ab- lage-/Paketkonventionen.

3.5.3. Lieferobjekt, Turnus und Abgrenzungen

(1) Ein Lieferpaket ist die technische Einheit einer Bereitstellung. Es umfasst alle Dateien, die für einen defi- nierten Betriebstag (oder einen klar benannten Zeitraum) gemeinsam bereitgestellt werden.

(2) Jedes Lieferpaket erhält eine eindeutige delivery_id. Anforderungen:

• ausschließlich druckbare 7-Bit-ASCII-Zeichen (keine Umlaute), empfohlen: Kleinbuchstaben/Zif- fern/Bindestrich/Unterstrich

• eindeutig über alle Lieferungen eines Verkehrsvertrags/Teilnetzes

• Länge empfohlen ≤ 64 Zeichen

• Empfohlenes Schema: yyyymmdd-hhmmss-xxxx-vv (Datum, Erzeugungszeit, fortlaufend/zufäl- lig, Version).

(3) Wird ein Lieferpaket für denselben Zeitraum erneut bereitgestellt (Nachlieferung/Korrektur), ist dies ma- schinenlesbar kenntlich zu machen (z. B. delivery_version oder ein entsprechendes Feld im Manifest).

(4) Für die Verarbeitung in einem Hintergrungsystem ist sicherzustellen:

• alle im selben Importvorgang zu verarbeitenden Dateien liegen in einem gemeinsamen, flachen Ordner (keine Unterordner nach Fahrzeug/Datum etc.)

• keine ZIP-Archive im Importordner (sofern transportseitig komprimiert wird, muss am Ablageort entpackt bereitgestellt werden)

• alle Dateien eines Lieferpakets sind eindeutig der delivery_id zuordenbar (über Dateinamen und/oder Manifest)

3.5.4. Rohdaten gemäß VDV 457-2 (XML)

3.5.4.1. Allgemeines / Validierung

(1) Rohdaten sind als VDV 457-2 XML bereitzustellen.

(2) Jede XML-Datei muss schema-valide gegenüber der Schemadefinition nach VDV 457-2 sein.

(3) Beim Import kann eine Validitätsprüfung erfolgen; fehlerhafte Dateien müssen durch Protokollmeldungen identifizierbar sein.

3.5.4.2. Zulässige Granularitäten der Rohdaten-Dateien

Es sind zwei Bereitstellungsformen zulässig:

(1) Aggregierte Datei je Fahrzeug-Betriebstag

• Eine XML-Datei enthält genau eine PassengerCountingMessage, die

• sämtliche PassengerCountingEvent-Datensätze des Fahrzeug-Betriebstags in chronologischer Reihenfolge enthält.

(2) Einzeldateien je Zählereignis/Halt

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 32 von 41

[Seite 33]

• Eine XML-Datei enthält genau eine PassengerCountingMessage mit genau einem Passenger- CountingEvent.

• Die Reihenfolge wird über eine Sequenznummer im Dateinamen hergestellt.

3.5.4.3. Dateibenennung Rohdaten

(1) Aggregiert je Fahrzeug-Betriebstag:

• Empfohlenes Schema: FzgNr_YYYYMMDDhhmmss.xml

• FzgNr = Fahrzeugnummer (ohne Sonderzeichen),

• Zeitstempel = Zeitpunkt der Dateierzugung.

(2) Einzeldateien je Ereignis:

• Empfohlenes Schema: FzgNr_YYYYMMDDhhmmss_SeqNr.xml

• SeqNr = fortlaufende Sequenznummer über die Einzeldatensätze des betreffenden Fahrzeugs an diesem Betriebstag.

3.5.5. Ergebnis-/Protokollartefakt der Transformation und Zuordnung

3.5.5.1. Zweck

Zusätzlich zu den Rohdaten ist ein maschinenlesbares Ergebnis-/Protokollartefakt bereitzustellen, das Sta- tus-, Zuordnungs- und Qualitätsinformationen je Datensatz/Fahrt nachvollziehbar macht (insb. Sperr- gründe/Fehlercodes und Regel-/Parameterstand).

3.5.5.2. Mindestinhalt

Das Protokollartefakt muss je Datensatz mindestens enthalten:

• Referenzierung:

o bei zugeordneten Fahrten: Sollfahrt-ID/Fahrtnummer, Linie, Richtung, Datum/Betriebstag

o bei nicht zuordenbaren Datensätzen: interne Ereignis-/Rohdaten-Referenz (z. B. Fahrzeugeinheit und Zeitraum oder Rohdaten-ID)

• Status: mindestens „verwertbar“ / „nicht verwertbar“ (oder äquivalente Codierung)

• Sperrgrund/Fehlercode (bei „nicht verwertbar“ / ungültig / gesperrt / ausgeschlossen)

• Regel-/Parameterstand (Version/Stand der angewendeten Regeln/Parameter)

3.5.5.3. Format und Benennung

(1) Format: CSV (UTF-8), Semikolon als Trennzeichen, Kopfzeile mit Spaltennamen.

(2) Benennung: protokoll_<delivery_id>.csv (oder gleichwertig, eindeutig zur delivery_id).

3.5.6. Liefermanifest als Vollständigkeitsnachweis

(1) Zu jedem Lieferpaket ist ein maschinenlesbares Manifest bereitzustellen, das die technische Vollständig- keitsprüfung ermöglicht.

(2) Mindestinhalt Manifest:

• delivery_id, optional delivery_version

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 33 von 41

[Seite 34]

• Zeitraum/Betriebstag(e) der Lieferung

• Erzeugungszeitpunkt

• Quelle/Systemkennung

• Dateiliste mit Dateiname und Dateigröße; empfohlen zusätzlich Prüfsumme (z. B. SHA-256)

(3) Format (Empfehlung): JSON oder CSV; Benennung: manifest_<delivery_id>.json (oder gleichwertig).

3.5.7. Vollständigkeitsübersicht

Eine maschinenlesbare Übersicht bildet die Betriebsrealität fachlich ab und ermöglicht einen Abgleich zwi- schen „durchgeführten Fahrten“ und „gelieferten/zuordenbaren/verwertbaren Datensätzen“.

(1) Mindestinhalt je Fahrt: Datum/Betriebstag, Linie, Richtung, Sollfahrt-ID/Fahrtnummer (oder interne Refe- renz), Status (verwertbar/nicht verwertbar), Zuordnungsstatus, Sperrgrund/Fehlercode (falls zutreffend), Regel-/Parameterstand.

(2) Format (Empfehlung): CSV (UTF-8), Semikolon; Benennung: monatsliste_.csv.

3.5.8. Technische Grundlagen Bestandsformat RMV

Das nachfolgend beschriebene RMV-CSV-Format ist ein Bestands-/Sonderformat. Es ist nur anzuwenden, wenn dies für einen konkreten Anwendungsfall ausdrücklich vereinbart wurde. Für neue AFZS-Lieferungen ist primär VDV 457-2 (Rohdaten) maßgeblich; ergänzende Protokoll-/Statusdaten sind gemäß 3.5.5 bereit- zustellen.

3.5.8.1. Dateiaufbau

Ein Export besteht aus mehreren CSV-Dateien in ASCII-Kodierung. Die einzelnen Zeilen sind durch Wagen- rücklauf (Carriage-Return, ASCII-Code 13) und Zeilenvorschub (Linefeed, ASCII-Code 10) abzuschließen. Je Datei ist eine Tabelle abgelegt. Leerzeilen werden ignoriert.

3.5.8.2. Dateibezeichnung

Die Dateien haben die fest definierten Namenspräfixe ‚zaehlfahrt‘ und ‚messfahrt‘. Die Dateinamen dürfen ebenfalls nur druckbare Zeichen aus 7-Bit ASCII enthalten, also inbesondere keine Umlaute, wobei nur Klein- buchstaben, Unterstrich, Bindestrich und Ziffern verwendet werden dürfen, sowie ein einziger Punkt zur Ab- trennung der Dateiendung „.csv“. Dem Namenspräfix kann nach einem „_“ ein beliebiger alphanumerischer Ausdruck mit den gleichen Restriktionen als ID folgen. Ein zusammenhängender Export muss eine identische ID haben. Diese ID muss unter allen Zähldaten-Sendungen eindeutig sein. Eine empfohlene Zusammenset- zung enthält in dieser Reihenfolge Jahr, Monat und Tag der Lieferung (in der Form jjjjmmtt), fortlaufende Nummer innerhalb des Tages (vierstellig) und Versionsnummer der (evtl. wiederholten) Sendung (zweistellig).

Es spricht nichts dagegen Linienbezeichnungen und Fahrtkennzeichen in den Dateinamen aufzunehmen.

Der Dateiname darf inkl. Erweiterung („.csv“) nicht länger als 127 Zeichen sein.

Zulässiges Beispiel: zaehlfahrt.csv, messfahrt.csv zaehlfahrt_19790202.csv, messfahrt_19790202.csv

Unzulässiges Beispiel: Zaehldaten2232.csv, Haltestellen2232.csv // fehlender Unterstrich Zaehldaten_22.csv, Haltestellen_23.csv // unterschiedliche ID’s Zähldaten_22.csv, Haltestellen_22.csv // ungültiges Zeichen im Dateiname (‚ä‘)

Empfohlenes Beispiel: zaehlfahrt_20151203-1234-02.csv, messfahrt_20151203-1234-02.csv

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 34 von 41

[Seite 35]

Das Dateipräfix entspricht der Tabellenbezeichnung, welche in der Datei abgelegt ist.

3.5.8.3. Datei-Inhalt

Der innere Aufbau entspricht grundsätzlich dem einer klassischen CSV-Datei (siehe Glossar am Ende des Dokuments), mit dem Unterschied, dass in der ersten Zeile die Versionsnummer gefolgt von der Bezeichnung des bereitstellenden Systems aufgeführt sind. Beide Informationen sind durch ein Semikolon getrennt. Für dieses Dokument ist die Version ‚v1‘ anzuwenden. In der zweiten Zeile sind die Überschriften der Spalten aufgeführt. Die Reihenfolge der Spalten ist, wie in der nachfolgenden Tabelle definiert, einzuhalten, wobei grundsätzlich nur Großschreibung ohne Umlaute zulässig ist. Die Überschriften sind mit Semikolon voneinan- der getrennt. In den folgenden Zeilen sind die relevanten Daten aufgeführt.

3.5.8.4. Spaltenformat

In dieser Spezifikation werden diverse Spalten definiert. Folgende Datentypen werden verwendet:

Tabelle 6: Übersicht Spaltentypen bei AFZS-Meldungen

3.5.9. Tabellenmodell

Die Menge der benötigten Tabellen ist vom Funktionsumfang des zu versorgenden Auswertesystems abhän- gig. In der aktuellen Version dieser Spezifikation sind grundsätzlich die „AFZS Zählfahrt-Tabelle“ und die „Hal- testellen-Tabelle für AFZS Zählfahrten“ im Export zu definieren. Alle aufgeführten Spalten müssen vorhanden sein.

3.5.9.1. AFZS Zählfahrt-Tabelle

Beschreibung: Auflistung aller Zählfahrten mit allen relevanten Attributen. Für den PK (primary key) des RMV-seitigen Hintergrundsystems wird der Mandant (z.B. als Teil des Dateina- mens) und die ID in Feld 1 herangezogen. Je Mandant wird mit dem RMV eine Kennung für Feld 1 definiert, die in jedem Fall, auch bei mehreren Mandanten, RMV-seitig zu eindeutigen IDs führt.

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 35 von 41

[Seite 36]

Tabelle 7: AFZS Zählfahrt-Tabelle

*) Als Beispiel kann die nachfolgende Definition dienen: Die ID setzt sich zusammen aus: HBD (2 Stellen), ZugNr. (5 Stellen, nach links mit 0 aufgefüllt), Kalenderda- tum der Zugfahrt (6 Stellen: JJMMTT), UIC Fahrzeugnummer (12 Stellen).

3.5.9.2. Haltestellen-Tabelle für AFZS Zählfahrten

Beschreibung: Detaillierte Auflistung aller Haltestellen der aufgezeichneten Messfahrten, wobei die ID aus der Zählfahrttabelle vorhanden sein muss.

Tabelle 8: Haltestellen-Tabelle für AFZS Zählfahrten

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 36 von 41

[Seite 37]

4. Glossar, Begriffsdefinitionen

AGS

Amtlicher Gemeindeschlüssel {vormals Gemeindekennziffer (GKZ)}.

Aufbau:

Der Amtliche Gemeindeschlüssel (AGS) besteht bundesweit aus insgesamt 8 Ziffern, die sich wie folgt zu- sammensetzen:

• Die ersten beiden Ziffern bezeichnen das Bundesland

• Der Block von der dritten bis zur fünften Ziffer identifiziert den Landkreis bzw. die kreisfreie Stadt, dem die Gemeinde angehört. Die ersten fünf Stellen werden daher auch als Kreisschlüssel bezeichnet.

• Die letzten drei Ziffern schließlich unterscheidet die Gemeinden innerhalb eines Landkreises. Bei kreis- freien Städten stehen an dieser Stelle drei Nullen.

• Der RMV hat aufgrund der hessichen Kommunalstruktur drei weitere Ziffer angehängt die deshalb auch bei Angaben für andere Bundesländer anzuwenden sind. Diese drei Ziffer beinhalten die entsprechenden Ortsteile.

Weitere Erläuterungen siehe: https://de.wikipedia.org/wiki/Amtlicher_Gemeindeschl%C3%BCssel

AG

Auftraggeber

AN

Auftragnehmer

Betriebstag

Ein Betriebstag endet rechnerisch oft nach 24 Uhr, also am nächsten Kalendertag. Bisher wurde der Fahrplan dazu technisch bis z. B. 29 Uhr weitergezählt, damit Fahrten nach Mitternacht noch dem „alten Tag“ zugeord- net werden.

Diese Praxis entfällt: Fahrpläne gelten nun strikt kalendarisch von 0:00:00 bis 23:59:59 Uhr. Der Begriff „Be- triebstag“ bleibt jedoch inhaltlich bestehen.

Spätfahrten und Nachtbusse nach Mitternacht werden weiterhin entsprechend der Werktags-, Wochenend- oder Feiertagszuordnung des Vortages behandelt. Ein Bus um 2:00 Uhr am Samstagmorgen gilt also in der Regel als Teil des Betriebstages „Freitag“ und fährt nach dem Werktagsfahrplan.

Das Ende eines Betriebstages orientiert sich meist an der Betriebspause in den Nachtstunden. Fehlt diese – wie am Hbf Frankfurt – muss der Betriebstag künstlich definiert werden. Beispiel: Beginnt der Betriebstag um 5:00 Uhr, fährt ein Zug, der um 5:12 Uhr in Frankfurt ankommt, noch nach Freitagsfahrplan, während eine Straßenbahn, die um 5:02 Uhr startet, bereits nach Samstagsfahrplan verkehrt.

Für den RMV gilt konkret:

In § 6 Abs. 5 der „Gemeinsamen Beförderungsbedingungen“ ist der Betriebstag definiert.

Die Betriebstages Definition ist insbesondere für die tarifliche Gültigkeit von Zeitkarten, bspw. Tageskarten von Bedeutung. Nur in Bezug auf die tarifliche Gültigkeit gibt es im RMV überlappende Gültigkeitszeiträume. Die Gültigkeit einer Tageskarte bspw. beginnt um 0.00 Uhr des ausgestellten Kalendertages und endet am definierten Ende des Betriebstages.

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 37 von 41

[Seite 38]

Bei den Einteilungen von Fahrten eines Verkehrsmittels zu einem Betriebstag (die dann in der Fahrplandar- stellung zum Ausdruck kommt und Auswirkungen darauf hat, ob bspw. eine „Werktagsfahrt“ in der Fr/Sa- Nacht fährt oder nicht fährt) kann hingegen keine Überlappung möglich sein sondern ist eine punktgenaue Abtrennung der Betriebstage voneinander zwingend. Entscheidend für die Einteilung ist i.allg. der Zeitpunkt nach Soll-Fahrplan am Startpunkt der Fahrt. Bei einer Flügelung ist dies u.U. der Ort der Flügelung, sofern hier eine neue Fahrtnummer ins Spiel kommt.

BNV

BusNotVerkehr (im SPNV)

BPNV

Buspersonennahverkehr

Bündel

Kurzform für „Linienbündel“

csv Daten

csv Daten gibt es in unterschiedlichen Varianten. Entgegen der wörtlichen Übersetzung (comma separated values) werden csv Daten mit dem RMV in einem Format ausgetauscht, in dem die DatenFELD Trennung durch Semikola und NICHT durch Kommata vorgenommen wird. Naturgemäß haben die einzelnen Felder keine vorgegebene Länge (das Ende des Feldes wird ja erst durch ein Semikolon definiert). Die in den obigen Tabellen angegebenen Längen definieren daher nur die maximalen Längen die die Werte haben dürfen, damit das importierende System diese korrekt verarbeiten kann. Ähnliches gilt für die Feldtypen. Naturgemäß wer- den in einer csv Datei nur Zeichen gespeichert. Wenn also in den Definitionstabellen von Integer oder Nume- risch oder Float die Rede ist, dann wird damit ausgedrückt, dass die Zeichenkette ihrer inhaltlichen Bedeutung nach numerisch sein soll (also nur Zeichen enthalten darf, die ein importierendes System als Ziffern (oder Dezimaltrennzeichen) interpretieren kann, im dezimalen System also nur die Zeichen ‚0‘ bis ‚9‘ und evtl. ein Dezimaltrennzeichen).

Hinweis zum Typ ‚Numerisch‘. Als Dezimaltrennzeichen wird bei Verkaufsdaten (Tab. 7) das Komma verwen- det. Bei den Ausfall oder Teilausfalldaten hingegen wird der Punkt eingesetzt – nicht das Komma! Sofern im jeweiligen Abschnitt nicht anders beschrieben, sind csv Dateien grundsätzlich ohne Headerzeile zu liefern.

Die Datensatz Trennung erfolgt (gemäß Windows-Standard) mit CRLF (ASCII 13, ASCII 10).

Das Feldtrennzeichen (hier Semikolon) darf nicht Teil der Dateninhalte sein. Falls dies aus fachlichen Grün- den unvermeidlich sein sollte, können möglicherweise, dies aber nur nach Abstimmung im Einzelfall – je nach betroffenem System, Datenfeld-Inhalte auch mit doppelten Anführungszeichen (ASCII dez. 34) maskiert ge- liefert werden.

DHID siehe DxID

Erläuterung: Im Rahmen des DELFI+ Konsortiums wurden in Zusammenarbeit mit führenden Lösungsanbie- tern von ÖV-Software-Systemen Vorschläge ausgearbeitet die in jedem Verbund (bzw. Verkehrsunterneh- men) in Eigenregie genutzte Haltestellen-ID abzulösen durch eine globale, hierarchich strukturierte, europa- weit eindeutige Haltestellen-ID. Dies findet seinen Niederschlag in der VDV-Schrift 432. Die Hierarchie-Ebe- nen einer Haltestelle sind demnach jeweils durch einen eindeutigen Delimiter (Doppelpunkte) voneinander getrennt zu beschreiben. Die Länge der einzelnen Datenelemente ist grundsätzlich nicht vorgegeben; in der für Deutschland vorgesehenen Implementierung gibt es allerdings Festschreibungen. Bei Datenlieferungen

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 38 von 41

[Seite 39]

soll aber für die Gesamtlänge Speicherplatz für mindestens 25 Zeichen vorgesehen werden. (Der RMV fordert max. 40 Zeichen). Die Hierarchie-Ebene über der eigentlichen Haltestelleninformation stellt (in Deutschland) der Landkreis dar, der durch die AGS repräsentiert wird. Angestrebtes Ziel ist, dass jede im Landkreis exis- tierende Haltestelle von allen IT-Systemen nur mit ein und derselben ID angesprochen wird. Damit ist die Identität von Haltestellen (bzw. deren Unterobjekte wie Maste, Bereiche etc.) anhand der ID eindeutig erkenn- bar. Im aktuellen Zustand gibt es hingegen, je nach anfahrendem Verkehrsunternehmen oder bei geografi- schen Überlappungen bspw. bei Übergangstarifen, mehrere „in Verkehr befindliche“ IDs für das gleiche Hal- testellenobjekt. Hier kann die Identität häufig nur anhand des Namens oder der Koordinate mit hoher Wahr- scheinlichkeit, aber nie sicher ermittelt werden. Wesentlich für den Erfolg der eindeutigen globalen Haltestel- len-ID ist das Konzept, dass für deren Vergabe je lokal abgegrenztem Bereich oder anderweitig organisierter Abgrenzung (Deutschland=Landkreis) immer nur eine Instanz für die Vergabe der ID zuständig ist. Haltestel- lenobjekte können (gemäß VDV nicht zwingend, hingegen beim RMV bis zur Mastebene verpflichtend!) über weitere Detaillierungsebenen (wiederum mit Doppelpunkt abgetrennt) strukturiert dargestellt werden. Die Hie- rarchie reicht dabei über insgesamt bis zu 6 Ebenen (so das bisherige Konzept) bis zur Haltestelle (3. Ebene) über Haltestellenbereiche (4. Ebene z.B. Busbereich / Bahnsteig) und Haltestellenmasten (5. Ebene z.B. Bus- steig / Gleis) bis zur Halteposition (6. Ebene z.B. Gleisbereich). Die Anzahl der von links zu zählenden Dop- pelpunkte erteilt somit Auskunft über den Detaillierungsgrad des Haltestellenobjektes.

Der DELFI+ Vorschlag entspricht in Aufbau und Struktur dem IFOPT-Standard (Identification of Fixed Objects in Public Transport) und wird in ähnlicher Form bereits in Bayern verwendet (DEFAS)

Die Struktur der Haltestellen-ID (spezifisch für Deutschland) soll wie folgt aussehen (KS (Kreisschlüssel), (Ziffer 1-2: Bundesland, Ziffer 3-5: Landkreis/ kreisfreie Stadt)):

• Für Haltestellen: de: :

• Für Masten: de: : : :

• Für Halteposition: de: : : : :

(Bsp: „de:07339:32768“). Im Beispiel würde es sich eindeutig um „Oppenheim, In den Weingärten“ handeln. Eine Haltestelle des Verbundes RNN – hier in Benutzung als Haltestelle des Übergangstarifs zum RMV.

Die Dateninhalte können, beispielsweise bei der Angabe der Warte/Abfahrtsposition am Steig/Gleis, auch nicht-numerisch sein, wodurch sich lange Zeichenketten ergeben können.

Als Beispiel sei (fiktiv) die Abfahrtsposition eines Zuges im vorderen Gleisbereich eines Bahnhofs im Bereich der „A-Ebene“ skizziert: „de:06412:00010:A-EBENE:GLEIS24:ABSCHN-C“. Dieser String hat bereits 39 Zei- chen!

DxID (DHID, DLID, DTID, DFID)

Die nachfolgenden Erläuterungen sind als Hinweise und Beispiele zum leichtern Verständnis zu lesen. Bei Fehlern, Unklarheiten, Mehrdeutigkeiten und Diskrepanzen gilt nur die in der jeweils aktuellsten VDV Schrif- ten 432 & 433 vorliegende Fassung.

Hinweis: In Abgrenzung zur VDV Schrift hat der RMV allerdings für die DHID eine Begrenzung auf 40 Zeichen vorgesehen.

DHID: Deutschlandweit eindeutige Haltestellen-ID

DLID: Deutschlandweit eindeutige Linien-ID

DTID: Deutschlandweit eindeutige Teillinien-ID

DFID: Deutschlandweit eindeutige Fahrt-ID

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 39 von 41

[Seite 40]

Dies sind hierarchisch aufgebaute IDs die in o.g. VDV Schriften beschrieben sind. Die Trennung der Hierarchieebenen erfolgt durch Doppelpunkt.

Dabei wird die DLID aus organisatorischen Gründen immer als Kombination aus DLID und DTID und somit als DLID_DTID ausgegeben um bspw. versch. Lieferanten für die gleichen Linien in der Datenorganisation unterscheiden zu können. Die DTID enthält immer im vorderen Teil die DLID, stellt also nur eine Verfeinerung der DLID dar – insofern dies notwendig ist. Anderenfalls ist die DTID inhaltlich identisch zur DLID. Allerdings endet die DTID in diesem Fall mit einem Doppelpunkt. Damit wird kenntlich gemacht, dass es sich formal um eine DTID handelt. Der RMV exportiert daher (linie.csv) immer nur die DLID_DTID „Kombination“ (formal eine DTID), bspw.: „de:rmv:00000496:005“

Die DLID hierzu lautet: „de:rmv:00000496“

Falls es keine inhaltliche DTID „Ergänzung“ gibt (bspw. nur ein Lieferant, Unterscheidung nicht nötig) wäre im obigen Bsp…

… die DTID = de:rmv:00000496:

… die DLID = de:rmv:00000496

Globale Haltestellen-ID (siehe DHID)

ITCS → RBL

KW (Kalenderwoche)

Es gilt die Zählweise nach DIN 1355 / ISO 8601, nach der sich alle deutschen Kalenderhersteller richten.

Das bedeutet im Wesentlichen: Jeden Montag und nur montags beginnt eine neue KW.

Es gibt keine unvollständigen Kalenderwochen, ausnahmslos jede KW enthält genau 7 Tage (also auch die KW die evtl. den Jahreswechsel überlappt)

Die KW mit der Nummer 1 ist diejenige, die mindestens 4 Tage des neuen Jahres enthält. Die davor liegenden Tage des neuen Kalenderjahres gehören zur letzten KW des alten Kalenderjahres. Es gibt also keine KW mit der Nummer 0.

Hinweis: US-Amerikanische Kalenderhersteller zählen abweichend davon die KW1 bereits ab 1. Jan.

LNO

Lokale Nahverkehrsorganisation

RBL

Rechnergestütztes Betriebsleitsystem (englisch: ITCS)

SEV

SchienenErsatzVerkehr (im SPNV)

SPNV

Schienenpersonennahverkehr

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 40 von 41

[Seite 41]

Tarifwechsel

Der technische Tarifwechsel erfolgt üblicherweise (bei Ausnahmen / unterjährigem Tarifwechsel wird darüber konkret informiert) parallel zum europaweiten Fahrplanwechsel. Dieses ist seit vielen Jahren der dem 2.ten Samstag im Dezember folgende Sonntag 0 Uhr [nicht immer idt. zum 2. Sonntag des Dezember! (bspw. 2024)].

VDV

Verband Deutscher Verkehrsunternehmen (VDV) in dem rund 600 Unternehmen des Öffentlichen Personen- verkehrs und des Schienengüterverkehrs in Deutschland organisiert sind, und der im aktiven Dialog mit Politik und Wirtschaft steht. Er erarbeitet u.a. technische, betriebliche, rechtliche und wirtschaftliche Grundsätze die zum Teil als VDV-Schriften Nr. XYZ aufgelegt sind und z.T. Ausschreibungsgrundlage sind (siehe Anhänge).

VSV

Verkehrs-Service-Vertrag

VU

Verkehrsunternehmen

XSD -> XML

XML

Modernes technisches Datenformat zum elektronischen Datenaustausch. Wird häufig im online basierten Datenaustausch eingesetzt. Steht in Zusammenhang mit einer XSD Vorlage in der die jeweilige Definition des konkreten Datenformates in maschinenauswertbarer Form beschrieben ist.

E Anlage 17 RMV Datenhandbuch Version 3_47_00_MVU_2026-04-17 (Datenhandbuch des RMV) Seite 41 von 41