Jedes Verkehrsunternehmen, das Echtzeitdaten veröffentlicht, steht früher oder später vor derselben Frage: Auf welchen Standard soll sich das Netz festlegen? Meist wird die Antwort als technisches Detail behandelt, das derjenige entscheidet, der den Feed konfiguriert. Sie ist kein technisches Detail. Die Wahl bestimmt, welche Plattformen Ihre Daten nutzen können, welche Aufgabenträger sie akzeptieren und wie viel Integrationsaufwand jeder neue Partner im nächsten Jahrzehnt verursacht.
Dieser Artikel vergleicht die beiden Standards auf Architekturebene. Wie Echtzeitfeeds in der Praxis direkt aus dem Betrieb entstehen, zeigt unser Modul Operations.
Die beiden Standards in je einem Absatz
GTFS-Realtime erweitert die statische GTFS-Spezifikation. Es wurde von Google entwickelt, um Fahrplanauskünfte für Endkunden zu versorgen, und erbt die größte Stärke von GTFS: Einfachheit. Drei Feedtypen decken fast alles ab, was ein Verkehrsunternehmen veröffentlichen muss, nämlich Fahrtaktualisierungen (Trip Updates), Fahrzeugpositionen (Vehicle Positions) und Störungsmeldungen (Service Alerts). Das Datenmodell ist bewusst schmal gehalten, sodass Feeds schnell erzeugt und schnell verarbeitet werden.
SIRI, das Service Interface for Real Time Information, ist ein europäischer CEN-Standard. Es wurde von und für Aufgabenträger entwickelt, und das merkt man: ein reichhaltigeres Datenmodell, mehr Dienstarten und ausdrückliche Unterstützung für abgestimmte Datenaustausche zwischen Systemen statt einseitiger Veröffentlichung. SIRI bildet Konzepte ab, die GTFS-RT nicht ausdrücken kann, etwa eine detaillierte Anschlusssicherung zwischen Fahrten oder strukturierte Beschreibungen von Störungslagen.
Wo welcher Standard tatsächlich gewinnt
Der Vergleich wird erst nützlich, wenn man betrachtet, wer die Daten nutzt.
GTFS-RT gewinnt bei der Reichweite beim Fahrgast. Google Maps, Moovit, Transit und die meisten Fahrplanauskünfte von Drittanbietern verarbeiten GTFS-RT nativ. Wenn Ihr Ziel Sichtbarkeit beim Fahrgast ist, ist das der kürzeste Weg, und eine realistische Alternative gibt es nicht.
SIRI gewinnt bei der institutionellen Integration. Nationale und regionale Zugangspunkte in ganz Europa sind um SIRI-Profile herum aufgebaut. Wenn ein regionaler Aufgabenträger Daten von zwanzig Verkehrsunternehmen bündelt, wird er fast sicher SIRI vorschreiben, weil der Standard genau für dieses Bündelungsproblem entworfen wurde. Das gilt besonders in den nordischen Ländern, wo die nationalen Dateninfrastrukturen ausgereift sind und Spezifikationen durchgesetzt statt nur empfohlen werden.
SIRI gewinnt bei der Ausdrucksstärke. Strukturierte Störungsinformationen, die Unterscheidung zwischen geplanten und ungeplanten Ereignissen sowie Umstiegskonzepte haben in GTFS-RT keine saubere Entsprechung. Wenn Ihr Netz auf garantierte Anschlüsse zwischen Fahrten angewiesen ist, zwingt Sie GTFS-RT, Informationen zu vereinfachen, die Sie eigentlich brauchen.
GTFS-RT gewinnt bei den Betriebskosten. Weniger Nachrichtentypen, weniger Profilabstimmung, kleinere Datenmengen, mehr verfügbare Werkzeuge. In einem kleinen oder mittleren Netz ist der Unterschied beim Implementierungs- und Wartungsaufwand real.
Die Frage ist nicht welcher, sondern welcher zuerst
Die Entscheidung als Entweder-oder zu betrachten, ist der häufigste Fehler. In der Praxis veröffentlichen die meisten europäischen Verkehrsunternehmen am Ende beide, weil die beiden Standards zwei verschiedene Zielgruppen bedienen, die sich nicht gegenseitig ersetzen.
Die richtige Frage betrifft daher Reihenfolge und Architektur. Welchen Feed brauchen Sie zuerst, angesichts Ihrer unmittelbaren Pflichten und Ihrer Sichtbarkeitsziele? Und kann Ihr System den zweiten später ohne Neuaufbau erzeugen?
Diese zweite Frage ist die, die über zehn Jahre zählt. Wird der Echtzeitzustand in einem einzigen internen Modell gehalten und werden Standards als Ausgabeformate behandelt, ist ein zusätzlicher Feed eine Konfigurationsaufgabe. Ist der Standard fest im Kern des Systems verankert, wird der zweite zum Projekt.
Die fünf Fragen an einen Anbieter
Stellen Sie diese Fragen, bevor Sie Funktionslisten vergleichen.
Welche Feeds laufen heute produktiv, und für welche Kunden? Unterstützt heißt nicht im Betrieb. Fragen Sie nach einer Live-Feed-URL und dem Namen eines Verkehrsunternehmens, das sie nutzt.
Welches SIRI-Profil, und in welcher Version? SIRI ist eine Familie von Spezifikationen, und nationale Profile unterscheiden sich. Ein Anbieter, der SIRI allgemein unterstützt, unterstützt nicht unbedingt das Profil, das Ihr regionaler Aufgabenträger tatsächlich verlangt.
Können beide Feeds gleichzeitig aus denselben Daten laufen? Erfordern GTFS-RT und SIRI zwei getrennte Datenstrecken, pflegen Sie zwei Sätze von Inkonsistenzen.
Wie hoch ist die End-to-End-Latenz? Messen Sie vom Ereignis am Fahrzeug bis zu dem Moment, in dem der Feed für einen Abnehmer lesbar ist, nicht ab dem internen Datenbankeintrag. Im Unterschied zwischen beiden Werten liegt oft das eigentliche Problem.
Wie werden Störungsmeldungen behandelt? Hier gehen die Implementierungen am stärksten auseinander. Ein Disponent, der eine Störung einmal erfasst, sollte in beiden Standards eine gültige Meldung erzeugen, ohne sie erneut einzugeben.
Was das für Ihre Ausschreibung bedeutet
Schreiben Sie nicht, dass die Lösung GTFS-RT- und SIRI-konform sein muss. Konformität behauptet jeder, und niemand prüft sie.
Spezifizieren Sie stattdessen beobachtbares Verhalten. Benennen Sie die genauen geforderten Feeds und für jeden die Profilversion. Legen Sie eine maximale End-to-End-Latenz fest und wie sie bei der Abnahmeprüfung gemessen wird. Verlangen Sie, dass eine einzige Aktion des Disponenten in allen veröffentlichten Feeds konsistente Ausgaben erzeugt. Verlangen Sie, dass historische Feeddaten exportierbar sind.
Diese vier Anforderungen sind bei der Abnahme prüfbar. Konformitätserklärungen sind es nicht.
Wohin die Entwicklung geht
Die beiden Standards nähern sich im Umfang an, verschmelzen aber nicht. Plattformen für Endkunden zeigen keine Anzeichen, SIRI zu übernehmen, und europäische Aufgabenträger keine Anzeichen, es aufzugeben. Anzunehmen, dass der eine den anderen aufnehmen wird, und darauf aufzubauen, ist die eine Entscheidung, die schlecht altert.
Die dauerhafte Position ist eine Frage der Architektur, nicht der redaktionellen Wahl: den Echtzeitzustand in einem einzigen internen Modell halten, jeden Standard als Ausgabe behandeln und das Hinzufügen des nächsten zu einer Konfigurationsänderung machen. Mit dieser Architektur ist das Hinzufügen von SIRI zu einem bestehenden GTFS-RT-Feed eine Konfigurationsaufgabe. Ohne sie wird dieselbe Änderung zu einem eigenen Projekt mit eigenem Budget.
Häufig gestellte Fragen
Was ist der Unterschied zwischen SIRI und GTFS-RT?
GTFS-Realtime erweitert die statische GTFS-Spezifikation und wurde von Google entwickelt, um Fahrplanauskünfte für Endkunden zu versorgen, mit drei Feedtypen und einem bewusst schmalen Datenmodell. SIRI ist ein europäischer CEN-Standard, der für Aufgabenträger entwickelt wurde, mit einem reichhaltigeren Datenmodell, mehr Dienstarten und Unterstützung für abgestimmte Datenaustausche zwischen Systemen.
Welchen Standard nutzen Google Maps und Fahrplan-Apps?
GTFS-RT. Google Maps, Moovit, Transit und die meisten Fahrplanauskünfte von Drittanbietern verarbeiten GTFS-RT nativ, deshalb ist es der kürzeste Weg zur Sichtbarkeit beim Fahrgast.
Sollte ein Verkehrsunternehmen SIRI oder GTFS-RT veröffentlichen?
In der Praxis veröffentlichen die meisten europäischen Verkehrsunternehmen am Ende beide, weil die Standards Zielgruppen bedienen, die sich nicht gegenseitig ersetzen. Die eigentlichen Entscheidungen sind, welchen Feed Sie angesichts Ihrer Pflichten und Sichtbarkeitsziele zuerst brauchen und ob Ihr System den zweiten später ohne Neuaufbau erzeugen kann.
Wie formuliert man Echtzeitanforderungen in einer Ausschreibung?
Spezifizieren Sie beobachtbares Verhalten statt Konformität: die genauen Feeds und für jeden die Profilversion, eine maximale End-to-End-Latenz und wie sie bei der Abnahme gemessen wird, konsistente Ausgaben in allen Feeds aus einer einzigen Aktion des Disponenten sowie exportierbare historische Feeddaten.
Sie fragen sich, welchen Feed Ihr Netz zuerst veröffentlichen sollte? Das Team von Pysae geht mit Ihnen Ihre Pflichten und Ihre aktuelle Datenbasis durch.