Mautsystem-Interoperabilität: was EETS vom Backend verlangt

Interoperabilität im Mautsystem wird in der öffentlichen Darstellung meist als Gerätefrage behandelt: ein Bordgerät, das in mehreren Ländern funktioniert. Technisch liegt der Aufwand woanders. Der europäische elektronische Mautdienst, kurz EETS, stellt Anforderungen an das Backend, die tiefer gehen als eine zusätzliche Schnittstelle. Sie betreffen die Rollentrennung, den Identitätsnachweis zwischen fremden Parteien und die Frage, wer eine bestrittene Fahrt klärt. Dieser Artikel ordnet ein, was davon Architektur ist und was Konfiguration.

Was der Rechtsrahmen tatsächlich vorgibt

EETS geht auf die Richtlinie (EU) 2019/520 und die zugehörige Durchführungsverordnung zurück. Das Ziel ist, dass ein Nutzer mit einem Vertrag und einem Bordgerät sämtliche mautpflichtigen Strecken in der Union befahren kann, unabhängig davon, wer die einzelne Strecke bemautet.

Für die Systemlandschaft folgt daraus eine Rollentrennung, die vorher in dieser Schärfe nicht existierte:

• Der Mauterheber betreibt eine Mautdomäne, legt Tarife fest und stellt die Erhebung sicher. Er hat keine direkte Vertragsbeziehung zu allen Nutzern, die seine Strecken befahren.
• Der EETS-Anbieter hat den Vertrag mit dem Nutzer, gibt das Bordgerät aus, rechnet gegenüber dem Nutzer ab und tritt gegenüber dem Mauterheber für dessen Forderungen ein.

Diese Trennung ist der Kern. Alles, was an technischen Anforderungen folgt, lässt sich daraus ableiten, und die meisten Umstellungsprobleme entstehen genau dort, wo ein bestehendes System diese Trennung nicht kennt.

Warum bestehende Backends daran scheitern

Ein Mautsystem, das über Jahre für eine einzige Domäne gewachsen ist, trägt eine Annahme im Datenmodell, die selten explizit gemacht wurde: dass jede erfasste Fahrt zu einem Nutzer gehört, den das eigene System kennt, und dass die Forderung aus dieser Fahrt gegenüber diesem Nutzer geltend gemacht wird.

Unter EETS gilt beides nicht mehr zwangsläufig. Eine erfasste Fahrt kann zu einem Nutzer gehören, dessen Vertragsdaten in einem fremden System liegen und für den eigenen Betreiber nicht einsehbar sind. Die Forderung richtet sich nicht an den Fahrer, sondern an den EETS-Anbieter, der den Fahrer vertritt.

Dieser Begriff, also ein Vertragsverhältnis, das außerhalb des eigenen Systems besteht und trotzdem eine Forderung trägt, muss in das Datenmodell eingezogen werden. Das ist keine Erweiterung um ein Feld. Es betrifft die Zuordnung von Fahrten, die Forderungsverwaltung, die Klärung von Einsprüchen und die Berichterstattung, und es berührt in gewachsenen Landschaften eine große Zahl bestehender Verbindungen. Wie sich ein solcher Eingriff in eine bestehende Integrationslandschaft einordnen lässt, behandeln wir in Systemintegration für geschäftskritische Systeme.

Identität und Vertrauen zwischen fremden Parteien

Der Datenaustausch findet zwischen Organisationen statt, die keine gemeinsame Infrastruktur und keine gemeinsame Benutzerverwaltung haben. Beide Seiten müssen sich gegenseitig zweifelsfrei ausweisen, und der Nachweis muss maschinell und dauerhaft funktionieren.

Die Umsetzung läuft über gegenseitige Authentifizierung mit Zertifikaten. Das ist technisch etabliert, erzeugt im Betrieb aber eine Klasse von Problemen, die in Projektplänen regelmäßig fehlt:

• Zertifikate laufen ab. Ein abgelaufenes Zertifikat unterbricht den Austausch mit einer Gegenstelle vollständig. Da die Laufzeiten mehrjährig sind, fällt der erste Ablauf in eine Phase, in der niemand mehr an den Vorgang denkt. Erneuerung und Überwachung gehören automatisiert, nicht in eine Kalendererinnerung.
• Die Zahl der Gegenstellen wächst. Jeder zusätzliche Anbieter und jede zusätzliche Domäne bringt eigene Zertifikate, eigene Endpunkte und eigene Wartungsfenster mit. Was bei drei Gegenstellen manuell beherrschbar ist, ist bei dreißig eine eigene Betriebsaufgabe.
• Zugriffsrechte sind feingranular. Ein Anbieter darf Fahrten sehen, die seinen Nutzern zugeordnet sind, und keine anderen. Diese Abgrenzung ist eine Berechtigungsentscheidung auf Datenebene, nicht auf Systemebene, und sie muss auch dann tragen, wenn ein Auswertungswerkzeug direkt auf den Bestand zugreift.

Der dritte Punkt ist der, der am häufigsten unterschätzt wird. Eine Zugriffsentscheidung, die nur an der Schnittstelle geprüft wird, lässt sich über jeden anderen Zugangsweg umgehen. Wir setzen die Rechteprüfung deshalb an einem zentralen Punkt auf und nicht je Anwendung; das Vorgehen dazu beschreibt unsere Leistung zur IAM-Beratung mit Keycloak, die technische Umsetzung der Artikel Keycloak als IAM im Unternehmen.

Abrechnung über Domänengrenzen

Der wirtschaftlich heikelste Teil ist die Abrechnung zwischen Mauterheber und Anbieter, weil hier Forderungen zwischen Organisationen mit gegenläufigen Interessen entstehen.

Der Regelfall ist unproblematisch: Eine Fahrt wird erfasst, dem Anbieter zugeordnet, in die periodische Abrechnung aufgenommen und beglichen. Der Aufwand entsteht in den Ausnahmen, und die Ausnahmen sind bei den Mengen, um die es geht, absolut betrachtet zahlreich.

Drei Fälle bestimmen die Architektur:

• Die bestrittene Fahrt. Der Anbieter widerspricht einer Position, weil das Fahrzeug nach seinen Daten nicht dort war, das Bordgerät zum Zeitpunkt nicht aktiv war oder die Klassifizierung nicht stimmt. Für die Klärung braucht es einen definierten Ablauf mit Fristen, einen belastbaren Nachweis auf Seite des Erhebers und eine Entscheidung, die beide Seiten nachvollziehen können.
• Die verspätete Fahrt. Erfassungsdaten treffen nicht immer zeitnah ein, etwa bei Geräten mit unterbrochener Verbindung. Ein Datensatz, der nach dem Abschluss einer Periode eintrifft, muss einer Nachverrechnung zugeführt werden, ohne die bereits abgeschlossene Periode zu verändern.
• Die nicht zuordenbare Fahrt. Eine Erfassung ohne gültige Zuordnung zu einem Anbieter darf nicht verloren gehen. Sie gehört in einen Klärungsbestand mit Wiedervorlage, dessen Größe eine Betriebskennzahl ist.

Für alle drei gilt dieselbe Anforderung: Jede Position muss von der Erfassung bis zur Abrechnungszeile lückenlos nachvollziehbar sein, mit Zeitstempel, Quelle und jedem Verarbeitungsschritt. Ohne diese Nachvollziehbarkeit ist eine Klärung nicht führbar, und der Erheber trägt im Zweifel den Ausfall.

Der Nachweis der Erfassung trägt die Beweislast

Unter EETS verschiebt sich die Beweislage. Solange Erheber und Anbieter dieselbe Organisation waren, blieb ein Zweifel an einer Erfassung ein internes Qualitätsthema. Sobald die Forderung gegen eine fremde Organisation gerichtet ist, wird derselbe Zweifel zu einem Streitfall mit wirtschaftlicher Folge.

Was einen Nachweis belastbar macht, entscheidet sich zum Zeitpunkt der Erfassung, nicht zum Zeitpunkt des Streits. Drei Eigenschaften sind dafür maßgeblich:

• Die Erfassung ist mehrfach belegt. Eine Zuordnung, die allein auf dem Signal des Bordgeräts beruht, lässt sich schwerer verteidigen als eine, die durch eine unabhängige Beobachtung gestützt wird. Wo eine zweite Quelle vorhanden ist, gehört sie zum Datensatz, nicht in ein getrenntes System.
• Der Datensatz ist unveränderlich abgelegt. Jede spätere Korrektur muss als eigener Vorgang mit Zeitstempel und Urheber erkennbar bleiben. Ein Bestand, in dem Sätze überschrieben werden können, verliert seinen Beweiswert vollständig, unabhängig davon, ob je überschrieben wurde.
• Die Aufbewahrungsfrist ist an der Klärungsfrist ausgerichtet. Wenn Nachweise gelöscht werden, bevor der letzte mögliche Einspruch verjährt, entsteht eine Lücke, die genau dann auffällt, wenn sie teuer ist. Diese Abstimmung zwischen Datenschutz und Beweisbedarf gehört vor den Betrieb, nicht in eine spätere Klärung.

In der Praxis ist der zweite Punkt der, an dem bestehende Systeme am häufigsten nachgerüstet werden müssen. Erfassungsbestände sind historisch als Arbeitsdaten gebaut worden, mit Korrekturmöglichkeit durch den Betrieb, weil das im Einbetrieb sinnvoll war. Im Mehrparteienbetrieb ist es genau das, was eine Gegenseite angreifen wird.

Fahrzeugklassen und Tarife als Stammdatenproblem

Die Fahrzeugklassifizierung ist zwischen den Mitgliedstaaten nicht einheitlich. Achszahl, zulässiges Gesamtgewicht, Emissionsklasse und Anhängerstatus gehen in unterschiedlicher Gewichtung in die Einstufung ein, und dieselbe Fahrzeugkonfiguration kann in zwei Domänen in unterschiedliche Klassen fallen.

Der Fehler, der daraus regelmäßig entsteht, ist die Behandlung dieser Abbildung als Teil der Tariflogik. Sobald die Umrechnung zwischen Klassifizierungsschemata im Code der Bewertung liegt, ist jede Tarifänderung in einem Land ein Eingriff in Software, und jede neue Domäne ein Entwicklungsvorhaben.

Tragfähiger ist, die Abbildung als versionierte Stammdaten zu führen, mit Gültigkeitszeiträumen, und die Bewertung diese Stammdaten lesen zu lassen. Eine Tarifänderung wird dann zu einem Datenvorgang mit Freigabe, nicht zu einer Auslieferung. Die Gültigkeitszeiträume sind dabei nicht optional: Eine Fahrt aus dem Vormonat muss nach dem Tarif bewertet werden, der zum Fahrzeitpunkt galt, auch wenn die Bewertung nachträglich erfolgt. Die allgemeine Form dieses Problems behandeln wir im Artikel zum Stammdatenmanagement im Unternehmen.

Der Betrieb im Mehrparteienmodell

Interoperabilität verändert nicht nur die Architektur, sondern den laufenden Betrieb, und dieser Teil steht selten im Projektauftrag.

Im Einbetrieb war eine Störung ein internes Ereignis mit einem Verantwortlichen. Im Mehrparteienbetrieb betrifft dieselbe Störung Gegenstellen, die eigene Betriebszeiten, eigene Eskalationswege und eigene Wartungsfenster haben. Daraus folgen drei Anforderungen, die vor der ersten Anbindung geklärt sein sollten.

Erstens braucht jede Gegenstelle einen benannten technischen Kontakt und eine vereinbarte Reaktionszeit. Ohne diese Vereinbarung dauert die Klärung einer Übertragungsstörung so lange, wie die langsamere Seite braucht, und die Forderungen laufen währenddessen weiter auf.

Zweitens müssen Wartungsfenster abgestimmt sein. Eine Gegenstelle, die ihre Schnittstelle ohne Vorankündigung abschaltet, erzeugt auf der eigenen Seite einen Rückstau, dessen Abbau länger dauert als die Unterbrechung selbst. Bei täglichen Mengen im sechsstelligen Bereich ist ein Rückstau von wenigen Stunden bereits ein eigener Vorgang.

Drittens braucht die Überwachung eine Sicht je Gegenstelle. Eine Gesamtkennzahl über alle Anbieter verdeckt den Ausfall einer einzelnen Verbindung so lange, bis er groß genug ist, um die Summe zu bewegen. Bis dahin sind Tage vergangen. Die Überwachung muss je Verbindung melden, dass seit einem definierten Zeitraum keine Daten mehr eingegangen sind, und dieser Zeitraum muss sich am normalen Rhythmus der jeweiligen Gegenstelle orientieren statt an einem globalen Wert.

Ein gangbarer Umstellungspfad

Für Betreiber mit einem bestehenden, funktionierenden Mautsystem ist die vollständige Neuentwicklung selten die richtige Antwort. Der Pfad, der sich in der Praxis bewährt, verläuft in vier Schritten.

Zuerst wird das Datenmodell um das fremde Vertragsverhältnis erweitert, ohne die bestehende Verarbeitung zu verändern. Dann entsteht die Austauschschicht zu den Gegenstellen als eigene Komponente vor dem Kernsystem, sodass das Kernsystem die Protokolldetails nicht kennt. Anschließend läuft der Betrieb mit einer einzigen Gegenstelle über einen vollständigen Abrechnungszyklus, einschließlich mindestens eines bestrittenen Falls, weil erst dieser Fall den Klärungsweg prüft. Erst danach folgt die Aufnahme weiterer Anbieter.

Der dritte Schritt ist der, der am häufigsten verkürzt wird. Ein Zyklus ohne Streitfall beweist, dass der Regelfall läuft. Der Regelfall war nicht das Risiko.

Unsere Arbeit an Mautsystem-Lösungen setzt in der Regel an dieser Stelle an: nicht bei der Frage, ob ein System interoperabel werden kann, sondern bei der Frage, welche Annahme im bestehenden Datenmodell dem im Weg steht. Diese Annahme ist fast immer dieselbe, und sie ist fast nie dokumentiert.