Lade- & Strompreis-App auf Basis von AFIR-/DATEX-II-Daten

Die europäische Verordnung über den Aufbau der Infrastruktur für alternative Kraftstoffe (AFIR) verlangt, dass statische und dynamische Daten zu Ladepunkten – Standort, Anschlussart, Leistung, Verfügbarkeit, Ad-hoc-Preis – über offizielle Zugangspunkte bereitstehen. Ausgeliefert werden sie dort nicht als handliche REST-API, sondern – bei den in diesem Projekt angebundenen Quellen – als DATEX-II-Publikationen: ein modellgetriebener europäischer Standard mit tief verschachtelten XML-Strukturen, sehr vielen optionalen Feldern und Unterschieden zwischen Herausgebern und Standardversionen. Wer diese Daten in einer App zeigen will, muss zuerst das Format beherrschen – nicht das Frontend.

Der zweite Punkt ist Menge und Takt. Bestandsdaten kommen typischerweise als vollständige Momentaufnahmen in festen Intervallen, dynamische Statusinformationen deutlich häufiger. Naiv verarbeitet heißt das: bei jedem Durchlauf den kompletten Bestand neu schreiben, ohne zu wissen, was sich überhaupt geändert hat. Große Datenmengen im Backend zu verarbeiten bedeutet hier weniger mehr Rechenleistung als vielmehr: erkennen, was neu ist, und alles andere unangetastet lassen.

Dazu kommt die Semantik. Ein Ladestandort ist eine Hierarchie aus Standort, Station, Ladepunkt und Steckertyp; Identifikatoren müssen über Aktualisierungen hinweg stabil bleiben, sonst springen Punkte auf der Karte oder tauchen doppelt auf. Preisangaben sind selten eine einzige Zahl, sondern setzen sich aus Arbeits-, Zeit- und Grundkomponenten zusammen. Und „Echtzeit“ ist bei fremdbezogenen Daten immer nur so echt wie der Publikationstakt der Quelle – das gehört ins Datenmodell und in die Darstellung, statt weggerundet zu werden.

Die Architektur trennt drei Aufgaben sauber: Import, normalisierter Kern, Auslieferung. Der Import holt die DATEX-II-Publikationen der offiziellen Quellen, liest sie streamend statt als komplettes Dokument im Arbeitsspeicher, prüft sie gegen das Schema und übersetzt sie in ein eigenes, schlankes Domänenmodell. Der Standard endet damit an der Systemgrenze – alles dahinter arbeitet mit klaren, eigenen Begriffen.

Als Datenrückgrat dient ein skalierbares .NET-Backend. Die Wahl passt zur Art der Arbeit: schemagetriebenes XML im Dauerbetrieb. Statische Typisierung bildet ein modellgetriebenes Format direkt ab, die XML-Werkzeugkette erlaubt streamendes Lesen auch großer Momentaufnahmen bei flachem Speicherverbrauch, und langlaufende Hintergrunddienste mit geplanten Läufen sind erstklassig unterstützt. Import und Ausliefer-API skalieren getrennt, weil ihre Lastprofile nichts miteinander zu tun haben: der Import läuft stoßweise im Takt der Quellen, die API folgt dem Nutzerverhalten.

Die kontinuierliche Aktualisierung der Marktpreise läuft als eigener Takt neben den Bestandsdaten. Jeder Durchlauf vergleicht gegen den zuletzt bekannten Stand, sodass nur echte Änderungen Folgearbeit auslösen – Schreibzugriffe, Cache-Invalidierung, Aktualisierung der Kartenebene. Jeder Datensatz trägt dabei Herkunft und Zeitstempel mit sich. Das ist keine Kosmetik: Nur so lässt sich in der App ehrlich anzeigen, wie aktuell ein Wert ist, und im Fehlerfall auf Quelle und Zeitpunkt zurückführen, statt im Gesamtsystem zu suchen.

Auf der Client-Seite sprechen iOS und Android kein DATEX II, sondern eine bewusst schmale API. Kartenabfragen laufen ausschnittsbezogen über einen räumlichen Index und werden je nach Zoomstufe zusammengefasst, damit die übertragene Datenmenge an den sichtbaren Ausschnitt gekoppelt ist und nicht an die Größe des Gesamtbestands. Echtzeitdaten in einer Mobile App heißen deshalb nicht, alles ans Gerät zu schicken, sondern pro Ansicht genau das Nötige – aus vorbereiteten Lesemodellen, die auch dann antworten, wenn eine Originalquelle gerade nicht erreichbar ist.

• Marktpreise in Echtzeit
• Kontinuierliche Aktualisierung
• Ladepunkte auf der Karte
• Offizielle AFIR-/DATEX-II-Datenbasis
• Skalierbares .NET-Backend

Im Auftrag eines Kunden aus dem E-Mobility-Umfeld umgesetzt; das .NET-Backend läuft im Dauerbetrieb auf standardkonformer DATEX-II-Basis. Kundenspezifische Kennzahlen bleiben vertraulich – maßgeblich ist die verlässliche, skalierbare Datenverarbeitung im Hintergrund.

Bei Vorhaben, die auf offiziellen Datenstandards aufsetzen, liegt der Aufwand fast nie dort, wo er im Angebot vermutet wird. Die Oberfläche ist der überschaubare Teil; die Arbeit steckt in Parsing, Normalisierung, stabiler Identität und Änderungserkennung. Sinnvoll ist deshalb, sehr früh mit echten Publikationen zu arbeiten statt nur mit der Spezifikation – Abweichungen zwischen dokumentiertem Modell und tatsächlich geliefertem Inhalt sind bei standardisierten Quellen der Normalfall, nicht die Ausnahme.

Der zweite verallgemeinerbare Punkt betrifft den Begriff Echtzeit. Gemeint ist bei fremdbezogenen Daten praktisch immer „so aktuell wie die Quelle“ – das früh zu klären, erspart Architekturentscheidungen, die diese Grenze zu überlisten versuchen. Ein System, das Herkunft und Stand jedes Werts mitführt, ist im Betrieb deutlich ruhiger: Meldungen über vermeintlich falsche Daten lassen sich auf eine Quelle und einen Zeitpunkt zurückführen, statt zur Suche im Gesamtsystem zu werden.