AFIR Artikel 20 — EV-Ladetelemetrie europaweit über eine API

Die Verordnung über die Infrastruktur für alternative Kraftstoffe (AFIR) — (EU) 2023/1804 — ist eine der folgenreichsten europäischen Mobilitätsregelungen der letzten Jahre. Sie schreibt eine Mindestabdeckung mit Ladepunkten am TEN-T-Netz vor, regelt Zahlungsmethoden und — entscheidend für jeden Entwickler, der EV-bewusste Software baut — verlangt mit Artikel 20, dass jeder Mitgliedstaat über seinen National Access Point Echtzeit-Ladetelemetrie in DATEX II veröffentlicht.

Wenn Sie eine Routing-App, ein Flottenelektrifizierungs-Dashboard, eine Roaming-/Zahlungsplattform oder eine Ladenetz-Analytics-Lösung bauen, ist AFIR Artikel 20 die nützlichste Verordnung, die je für Sie geschrieben wurde. Der Haken: Jeder Mitgliedstaat setzt das auf eigenem Zeitplan, in eigenem Profil, hinter eigenem NAP um. Hier das Bild, wie wir es bei NAPSPAN sehen, wo wir AFIR-Daten kontinentweit in eine einzige API aggregieren.

Was Artikel 20 tatsächlich verlangt

Der relevante Text verpflichtet Ladepunktbetreiber (CPOs), folgende statische und dynamische Daten kostenlos und in maschinenlesbarer Form über den NAP bereitzustellen:

Statisch (einmalig, langsam veränderlich):

• Geokoordinaten der Ladestation und jedes Ladepunkts
• Anzahl der Anschlüsse pro Station
• Anschlusstypen (CCS, CHAdeMO, Typ 2, Tesla usw.)
• Maximale Leistung (kW) pro Anschluss
• Betreiberidentität und Kontakt
• Zugänglichkeit (24/7? eingeschränkt?)
• Akzeptierte Authentifizierungs- und Zahlungsmethoden
• Ad-hoc-Preis — der Preis, den ein vertragsloser Nutzer tatsächlich zahlt

Dynamisch (Echtzeit):

• Betriebsstatus (verfügbar, belegt, außer Betrieb, reserviert)
• Status pro Anschluss
• Zeitstempel der letzten Aktualisierung

Das Format muss DATEX II sein. Die Frequenz nahezu Echtzeit. Der Zugang kostenlos. So weit die Verordnung. Spannend wird es bei der Umsetzung.

Mobilitheks AFIR-Profil (Deutschland)

Deutschland war früher Mover. Mobilitheks AFIR-Profil für E-Ladestationen ging im August 2025 live und nimmt seitdem CPOs auf. Es läuft auf demselben Mobilithek-Broker, den wir in unserer mTLS-Anleitung besprochen haben — gleiche Client-Zertifikat-Authentifizierung, gleiches https://mobilithek.info:8443/...-URL-Muster, eine eigene Publikations-ID pro CPO.

Das Profil verwendet die DATEX-II-Erweiterung EnergyInfrastructure. Ein typischer Datensatz sieht etwa so aus:

<d2:payloadPublication
    xsi:type="ei:EnergyInfrastructureStatusPublication"
    xmlns:d2="http://datex2.eu/schema/3/common"
    xmlns:ei="http://datex2.eu/schema/3/energyInfrastructure">
  <ei:energyInfrastructureSiteStatus id="DE_CPO_NW_1234">
    <ei:refuelPointStatus id="CP1">
      <ei:status>available</ei:status>
      <ei:lastUpdated>2026-05-01T08:14:05Z</ei:lastUpdated>
    </ei:refuelPointStatus>
    <ei:refuelPointStatus id="CP2">
      <ei:status>occupied</ei:status>
      <ei:lastUpdated>2026-05-01T08:13:50Z</ei:lastUpdated>
    </ei:refuelPointStatus>
  </ei:energyInfrastructureSiteStatus>
</d2:payloadPublication>

Statische Daten kommen in einer separaten EnergyInfrastructureTablePublication. Die beiden werden über energyInfrastructureSiteStatus.id verknüpft — statisch einmal täglich, Status alle 30 bis 60 Sekunden.

Wo Mitgliedstaaten divergieren

AFIR setzt das Datenmodell. Den Rest entscheidet jeder NAP selbst:

Selbst ohne Profilunterschiede kommen so mindestens vier verschiedene Authentifizierungsabläufe und drei Transportvarianten zusammen. Und das sind nur die ersten sieben Mitgliedstaaten. Die Profile selbst variieren weiter: Manche NAPs liefern nur den dynamischen Status; andere nur den statischen Katalog; das AFIR-vorgeschriebene Paar aus beidem ist Ziel, aber die Durchsetzung läuft gestaffelt durch 2026 und 2027.

Das normalisierte Modell

In NAPSPAN landen AFIR-Daten in unserer generischen features-Tabelle mit feature_type = 'ev_charging'. Typspezifische Felder wandern in eine JSONB-properties-Spalte. Kein neues Schema für ein neues Land — nur ein neuer Adapter und ein neuer Register()-Aufruf.

{
  "id": "de_mobilithek_de_cpo_nw_1234",
  "type": "ev_charging",
  "country": "DE",
  "operator": "EnBW mobility+",
  "name": "EnBW HPC Köln-Nord",
  "latitude": 50.9851,
  "longitude": 6.9550,
  "properties": {
    "connectors": [
      {
        "id": "CP1",
        "standard": "CCS_COMBO_2",
        "max_power_kw": 300,
        "status": "available",
        "last_updated": "2026-05-01T08:14:05Z"
      },
      {
        "id": "CP2",
        "standard": "CCS_COMBO_2",
        "max_power_kw": 300,
        "status": "occupied",
        "last_updated": "2026-05-01T08:13:50Z"
      }
    ],
    "access_24_7": true,
    "payment_methods": ["contactless_card", "ad_hoc_qr", "roaming"],
    "ad_hoc_price_per_kwh_eur": 0.65
  }
}

Anschlussstandards normalisieren in ein festes Enum (CCS_COMBO_2, CHADEMO, TYPE_2, TESLA, NACS, CCS_COMBO_1). Status normalisiert in fünf Werte (available, occupied, reserved, out_of_service, unknown). Leistung als Ganzzahl in kW. Das properties-JSONB bewahrt alles, was das Quellprofil sonst noch mitbrachte, damit keine Information verloren geht.

Grenzüberschreitende Abfragen

Der Sinn der Normalisierung: Ein API-Aufruf liefert Ladepunkt-Status aus jedem Mitgliedstaat gleichzeitig.

Verfügbare CCS-Schnellladepunkte auf dem Korridor Berlin–Amsterdam, ≥ 150 kW:

curl "https://api.napspan.com/api/v1/features/corridor?\
type=ev_charging&\
from_lat=52.52&from_lng=13.40&\
to_lat=52.37&to_lng=4.90&\
buffer_km=15&\
connector=CCS_COMBO_2&\
min_power_kw=150&\
status=available" \
  -H "X-API-Key: your_key"

Ein Aufruf. Zwei NAPs (Mobilithek + NDW). Eine konsistente Antwortstruktur. Die Korridor-Abfrage nutzt PostGIS — wir puffern die Großkreis-Strecke um 15 km und schneiden mit jedem ev_charging-Feature, dessen Properties zum Filter passen.

Bounding-Box-Abfrage als GeoJSON, fertig für Leaflet:

curl "https://api.napspan.com/api/v1/features/geojson?\
type=ev_charging&\
bbox=2.0,49.5,7.5,51.5" \
  -H "X-API-Key: your_key"

Was das ermöglicht

Drei Produktkategorien werden materiell besser, sobald AFIR-Daten kontinentweit normalisiert und abfragbar sind:

EV-Routing und Reiseplanung

Die meisten EV-Routing-Engines nutzen heute Community-Datensätze (OpenChargeMap) oder pro Netz eigene APIs. Live-Verfügbarkeit außerhalb des eigenen Netzes fehlt. AFIR-gestützte Statusdaten lösen beides: live und kontinentweit. Routing-Engines können Lader bevorzugen, die jetzt verfügbar sind und den passenden Anschluss haben.

Flotten-Elektrifizierungs-Dashboards

Für einen Logistiker mit gemischten Flotten über Grenzen hinweg eliminiert eine einzige API für Verfügbarkeit + Leistung + Preis pro Land die Pro-Netz-Integrationsmatrix. Kombiniert mit SSTP-LKW-Parkdaten (ebenfalls über NAP) entsteht eine integrierte Plan-Oberfläche für Laden und Ruhezeiten.

Roaming- und Aggregator-Plattformen

OCPI ist das dominante Roaming-Protokoll; AFIR ist die regulatorische Offenlegungsschicht. Sie überlappen, sind aber nicht identisch. AFIR-Daten sind die kanonische Referenz für alles, was ein CPO offenlegen muss; OCPI transportiert betriebliche und kommerzielle Metadaten zwischen Roaming-Partnern. Aggregatoren brauchen beides. NAPSPAN behandelt AFIR als Wahrheit für Statisch-plus-Status und legt Betreiber-Referenzen offen, damit OCPI-Integrationen sauber andocken können.

Wichtige Einschränkungen

• Abdeckung ist ungleichmäßig. AFIR-Pflichten greifen gestaffelt durch 2026/2027. Nicht jeder CPO veröffentlicht bereits; nicht jeder Mitgliedstaat hat sein Profil finalisiert. Mit zunehmender Abdeckung im Jahresverlauf rechnen.
• Preis ist das messy Feld. „Ad-hoc-Preis" ist Pflicht, aber Betreiber veröffentlichen ihn unterschiedlich — pro kWh, pro Minute, pro Sitzung, mit Zeit-of-use-Stufen. Wir geben weiter, was die Quelle veröffentlicht; wir synthetisieren nicht.
• Status-Frische variiert. Manche CPOs pushen alle 30 Sekunden; andere alle 5 Minuten. Wir reichen den Quell-last_updated-Zeitstempel pro Anschluss durch, damit der Konsument selbst entscheidet, was ihm zu alt ist.
• OCPI bleibt relevant. AFIR ist regulatorische Offenlegung; OCPI ist betriebliche Verbindung. Wenn Sie ein Roaming-Hub sind, brauchen Sie OCPI weiterhin — AFIR-Daten ergänzen, ersetzen sie nicht.

Jetzt ausprobieren

Die API ist live mit einem kostenlosen Tarif (keine Kreditkarte):

• Live-Karte — den Ladestations-Layer einschalten
• API-Dokumentation — vollständige Endpunktreferenz
• Entwicklerportal — Anmelden und API-Schlüssel erhalten

Wenn Sie EV-Routing, Flottenelektrifizierung oder Ladenetz-Analytics auf europäischen Daten bauen, würden wir gerne wissen, welche Länder und CPO-Netze für Sie am wichtigsten sind. AFIR-Abdeckung wächst über die nächsten 18 Monate; die Reihenfolge, in der wir CPOs anbinden, richtet sich teils danach, welche unsere Kunden tatsächlich nutzen.