Flottenbetrieb

Flotten-RFID-Ladekarten: Leitfaden für den kommerziellen E-Flottenbetrieb

Wie Flotten-RFID-Ladekarten für den kommerziellen E-Flottenbetrieb funktionieren: kWh-Erfassung pro Fahrzeug, OCPP-Integration, steuerrelevante Aufzeichnungen, depotübergreifende Autorisierung und was beim Ausgeben von Karten an Fahrer zu beachten ist.

Artikeldetails

Veröffentlicht
2. Mai 2026
Lesezeit
8 Min. Lesezeit
Herausgeber
ChargeRFID
Zurück zu Ressourcen

Von ChargeRFID

Prüfmethode: Wir haben diesen Leitfaden anhand der unten aufgeführten Primärquellen zu Vorschriften und Protokollen sowie der Primärquellen der Hersteller geprüft. Die Produktempfehlungen spiegeln die Herstellerperspektive von ChargeRFID wider und sollten mit Ihrem Lesegerät, Ihrer Ladestation und Ihrem Backend überprüft werden.

Flotten-RFID-Ladekarten: Leitfaden für den kommerziellen E-Flottenbetrieb

Der Betrieb einer gewerblichen Flotte mit Elektrofahrzeugen verändert die Wirtschaftlichkeit des Ladens. Statt eines einzelnen Fahrers, der an einer Tankstelle mit seiner persönlichen Kreditkarte bezahlt, laden 50, 500 oder 5.000 Fahrer an Depots, öffentlichen Ladestationen und Ladestationen zu Hause. Jeder Ladevorgang erzeugt Kosten-, kWh- und steuerrelevante Daten, die korrekt in der Flottenmanagementsoftware ankommen müssen. Mit Flotten-RFID-Ladekarten werden diese Daten direkt an der Quelle erfasst.

Dieser Leitfaden erklärt, was eine Flotten-RFID-Ladekarte von einer Karte für Privatkunden unterscheidet, wie die Authentifizierungs- und Berichtskette funktioniert und was bei der Ausgabe von Karten im Rahmen eines gewerblichen E-Flottenprogramms zu spezifizieren ist.

Was unterscheidet eine Flotten-RFID-Ladekarte?

Eine Ladekarte übermittelt ein Token. Ob dieses Token einen Fahrer, ein Fahrzeug, ein Depot, eine Kostenstelle oder einen Vertrag repräsentiert, bestimmen die Flotten- und Lade-Backends. Eine einzelne Karte identifiziert nicht von sich aus alle diese Einheiten gleichzeitig.

Die Karte kann ein 13,56-MHz-Zugangsmittel mit AES-Authentifizierung oder eine andere mit dem Lesegerät kompatible Technologie verwenden. Entscheidend ist, wie ihre Kennung oder geschützte Anwendung bereitgestellt und in den Backends zugeordnet wird:

•kWh-Erfassung pro Fahrzeug – die UID der Karte wird im Flottenmanagementsystem einem bestimmten Fahrzeug zugeordnet, sodass jeder Ladevorgang einem Fahrzeug zugerechnet werden kann.
•Fahrerzuordnung – in Verbindung mit Fahrzeugtelematik ermöglicht die Karte der Flotte, die Energiekosten dem Fahrer zuzuordnen, der dem Fahrzeug an diesem Tag zugeteilt war.
•Depotbezogene Autorisierung – Gruppen im Backend können die Nutzung von Tokens auf bestimmte Depots beschränken. Kryptografische Schlüssel können nur dort eine zusätzliche Schutzebene bieten, wo Karten und Lesegeräte eine geschützte Anwendung nutzen.
•Steuerrelevante Aufzeichnungen – die steuerliche Behandlung im Vereinigten Königreich hängt davon ab, wem das Fahrzeug gehört, wo geladen wird, ob die Nutzung geschäftlich oder privat erfolgt und wie die Erstattung berechnet wird. Aufzeichnungen zu Ladevorgängen unterstützen die Berechnung, sind dadurch allein jedoch noch nicht programmspezifisch.

Wie die Flotten-RFID-Authentifizierung an OCPP-Stationen funktioniert

Der Autorisierungs- und Transaktionsablauf hängt von der OCPP-Version ab. Ein typischer Ablauf mit OCPP 1.6 sieht folgendermaßen aus:

Wenn ein Fahrer seine Flottenkarte an das Lesegerät einer Depot- oder öffentlichen Ladestation hält:

1.Die Station liest die UID aus und sendet Authorize.req an das zentrale System.
2.Das zentrale System prüft die UID anhand der Freigabeliste der Flotte, häufig gefiltert nach Depot, Fahrergruppe oder Fahrzeuggruppe.
3.Nach der Freigabe sendet die Station StartTransaction mit Feldern unter anderem für den Anschluss, den idTag-Wert, den Zeitstempel und den Zählerstand zu Beginn.
4.Am Ende des Ladevorgangs übermittelt StopTransaction die Transaktionskennung, den Zeitstempel, den Zählerstand am Ende und optionale Transaktionsdaten. Dauer, Energiemenge und ein abrechnungsbezogener CDR werden von nachgelagerten Systemen berechnet oder zusammengestellt; sie bilden keinen in die OCPP-1.6-Nachricht eingebetteten CDR.
5.Das Lademanagementsystem kann den Ladevorgang mit weiteren Informationen anreichern und Datensätze an das Reporting-Backend der Flotte senden. OCPP 2.x verwendet stattdessen das abweichende TransactionEvent-Modell und nicht das Start-/Stopp-Nachrichtenpaar von OCPP 1.6.

Bei Flotten, die sowohl im Depot als auch öffentlich laden, gelangen CDRs externer CPOs über OCPI-Roaming und den MSP der Flotte zurück in dieselbe Verarbeitungskette für das Reporting.

Fahrzeugbezogene und fahrerbezogene Kartenmodelle

Die meisten Flotten wählen zwischen zwei Modellen:

Fahrzeugbezogene Karten verbleiben beim Fahrzeug, etwa im Handschuhfach oder an einem Schlüsselanhänger. Vorteile: einfache Nutzung für Fahrer und einfache Neuzuordnung bei Fahrerwechseln. Nachteile: Die Karte wird bei einem Fahrzeugdiebstahl mitgestohlen, und das Verhalten einzelner Fahrer lässt sich nicht getrennt betrachten.

Fahrerbezogene Karten begleiten den Fahrer beim Wechsel zwischen Fahrzeugen. Vorteil: direkte Zuordnung zum jeweiligen Fahrer. Nachteile: Eine genaue Zuordnung von Fahrzeug und Fahrleistung erfordert weiterhin Zuordnungs- oder Telematikdaten. Die steuerliche Behandlung muss sich nach den geltenden HMRC-Regeln richten und ergibt sich nicht allein aus dem Kartenmodell.

Viele große Flotten geben beides aus: eine fahrerbezogene Karte zur Kostenzuordnung und einen fahrzeugbezogenen Schlüsselanhänger als zusätzliche Zugangsmöglichkeit und für eine einfache Nutzung.

Schlüsselverwaltung über mehrere Depots hinweg

Bei Flotten mit mehreren Depots kann die Autorisierung im Backend nach Token-Gruppe, Fahrzeug, Fahrer oder Standort durchgesetzt werden. Ein 13,56-MHz-Zugangsmittel mit AES-Authentifizierung unterstützt außerdem diversifizierte Anwendungsschlüssel, sofern die eingesetzten Lesegeräte eine geschützte Anwendung authentifizieren und nicht nur die öffentliche UID auslesen.

Bei einer korrekt konzipierten geschützten Anwendung können getrennte Schlüsselbereiche die Auswirkungen einer Schlüsselkompromittierung begrenzen. Ein Wechsel dieser Schlüssel erfordert dennoch einen dokumentierten Prozess für Lesegeräte, Karten, Sicherheitsmodule und Backend. Bei einem Autorisierungsverfahren auf Basis öffentlicher UIDs werden stattdessen einzelne Tokens oder Token-Gruppen im Backend gesperrt.

Vermeiden Sie einen gemeinsamen Anwendungsschlüssel für die gesamte Flotte. Führen Sie jedoch keine Kartenschlüssel ein, die von den Lesegeräten der Ladestationen und dem Backend gar nicht zur Authentifizierung verwendet werden. Stimmen Sie die Schutzmaßnahme auf die tatsächliche Autorisierungsarchitektur ab.

Reporting: Vom OCPP-CDR zur Auswertung für HMRC-Zwecke

Die Karte ist nur der Einstiegspunkt. Erst die Berichtskette macht ein Flottenprogramm finanziell nutzbar.

Ein typischer Ablauf für eine britische Flotte:

1.Der Fahrer hält die Karte an das Lesegerät → die Station autorisiert → der Ladevorgang läuft → der CDR wird erfasst.
2.Der CDR wird mit Fahrer-, Fahrzeug- und Depotmetadaten aus dem Flottenmanagementsystem angereichert.
3.Die Energiekosten werden anhand des vertraglich vereinbarten Tarifs berechnet, häufig zeitabhängig oder durch Weitergabe der Bezugskosten.
4.Soweit erforderlich, werden Fahrleistungsdaten und Angaben zum Ladeort zusammengeführt, um die einschlägige HMRC-Behandlung von Erstattungen oder geldwerten Vorteilen anzuwenden.
5.Die geprüften Ergebnisse können anschließend Prozesse der Lohnabrechnung, Kostenerstattung oder steuerlichen Bearbeitung unterstützen, die zu den Eigentumsverhältnissen am Fahrzeug und zum jeweiligen Anwendungsfall passen.

Die gesamte Kette von der Karte bis zum Bericht sollte prüfbar sein. Dieser Prüfpfad ergibt sich normalerweise aus den Zählerständen der Stationen, OCPP-Ereignissen, Ladevorgangs- und CDR-Datensätzen der CPOs/eMSPs, Tarifdaten, Token-Zuordnungen und Flottenmetadaten. Transaktions-MAC-Funktionen eines 13,56-MHz-Zugangsmittels mit AES-Authentifizierung erzeugen oder validieren den Lade-CDR im Backend nicht automatisch – insbesondere dann nicht, wenn eine Ladestation lediglich die Karten-UID ausliest.

Roaming für das Laden im Depot und an öffentlichen Stationen

Die meisten gewerblichen Flotten können ihren Betrieb nicht allein mit dem Laden im Depot abdecken. Langstreckenfahrer, Zustelldienste mit wechselnden Routen und Flotten mit Regelungen zum Laden zu Hause benötigen über dieselbe Karte auch Zugang zu öffentlichen Ladenetzen.

Hier sind die Veröffentlichung der Tokens und aktive Roaming-Vereinbarungen entscheidend. Eine von einem eMSP ausgegebene Flottenkarte kann bei vertraglich angebundenen CPOs funktionieren, die über einen Hub oder eine direkte OCPI/OICP-Verbindung erreichbar sind. Die Abdeckung sollte der aktuellen vertraglichen Netzwerkliste des eMSP entnommen werden. Die Gesamtzahl der an eine Plattform angeschlossenen Ladepunkte garantiert nicht, dass eine bestimmte Karte überall akzeptiert wird.

Die CDRs gelangen zurück zum MSP der Flotte, werden bei einem vertraglichen Aufschlagsmodell neu bepreist und fließen in dieselbe Verarbeitungskette für das Reporting wie die Ladevorgänge im Depot.

Was bei der Ausgabe von Flotten-RFID-Ladekarten zu spezifizieren ist

Eine beispielhafte Beschaffungscheckliste:

•Chip und Anwendung: mit den Lesegeräten kompatible Technologie; Schlüssel eines 13,56-MHz-Zugangsmittels mit AES-Authentifizierung nur dort einsetzen, wo das Lesegerät die geschützte Anwendung authentifiziert
•Material: recyceltes PVC als häufigste Option oder FSC-Holz für ESG-orientierte Programme
•Formfaktor: Karten nach ISO 7810 ID-1 sowie Schlüsselanhänger zur Befestigung am Fahrzeug
•Druck: vollfarbig mit Fahrzeug-/Fahrer-ID, Flottenlogo und Lasergravur zum Manipulationsschutz
•Codierung: vorcodierte UID, idTag im MSP-Format, depotspezifischer diversifizierter Schlüssel
•Roaming: Veröffentlichung der Tokens und aktive eMSP–CPO-Vereinbarungen für die benötigten Netzwerke
•Ersatzkartenverfahren: auf Pilotdaten gestützter Ablauf für Verlust, Sperrung, Ersatz und Synchronisierung
•Kaufmännische Konditionen: aktuelle Mindestbestellmenge, Preis, Lieferzeit und Ersatzbedingungen in einem schriftlichen Lieferantenangebot

Häufige Fehler bei Flottenkartenprogrammen

•Karten ausgeben, bevor die MSP-Integration betriebsbereit ist – Fahrer halten ihre Karten an das Lesegerät und werden abgewiesen, weil der idTag-Wert noch nicht registriert ist.
•Ein gemeinsamer Anwendungsschlüssel für die gesamte Flotte – vergrößert unnötig die Auswirkungen einer Kompromittierung, wenn tatsächlich geschützte Anwendungen genutzt werden.
•Kein Ersatzkartenprozess – verlorene Karten, Ersatz-Tokens und die Synchronisierung mit dem Backend bleiben ungeregelt.
•Lücken bei der Planung des öffentlichen Ladens – davon ausgehen, dass einfach weitere Depotladestationen installiert werden, statt Roaming von Anfang an einzuplanen.
•Nicht abgestimmtes UID-Format – verschiedene MSPs erwarten unterschiedliche idTag-Formate, etwa 4-Byte oder 7-Byte sowie hexadezimale oder dezimale Darstellung. Stimmen Sie dies ab, bevor Sie 5.000 Karten codieren.

Wie geht es weiter?

Ein Flotten-RFID-Ladekartenprogramm umfasst vier zentrale Spezifikationsbereiche: Chipsicherheit, Codierungsformat, Roaming-Abdeckung und Reporting-Integration. Stimmen diese Bereiche, werden die Karten zur unsichtbaren Infrastruktur: Fahrer halten ihre Karte an das Lesegerät, Energie fließt, und die Daten kommen korrekt in der Flottenbuchhaltung an.

Entdecken Sie unsere RFID-Ladekarten aus recyceltem PVC und FSC-Holz oder lesen Sie, wie wir Flottenkartenprogramme mit einem ausgewählten EV-Ladeprogramm und einem ausgewählten Flottenladeprogramm umgesetzt haben. Sprechen Sie mit uns über das Ladeprogramm Ihrer Flotte – wir helfen Ihnen, die passende Karte zu spezifizieren und mit Ihrem MSP abzustimmen.

Firmen-, Netz- und Produktnamen in diesem Artikel sind Marken der jeweiligen Inhaber. Sie werden beschreibend verwendet, um Systeme zu benennen, mit denen unsere Karten zusammenarbeiten. ChargeRFID ist ein unabhängiger Hersteller; dieser Artikel behauptet keine Verbindung, Partnerschaft oder Empfehlung.

Primärquellen

Offizielle Quellen, die zur Prüfung der Aussagen zu Vorschriften, Protokollen und technischen Eigenschaften auf Chipebene in diesem Leitfaden herangezogen wurden.

Teilen:

Nächster Schritt

Überführen Sie Ihre Recherche in eine Kartenspezifikation.

Teilen Sie uns die Angaben zu Lesegerät, Chip, Daten oder Rollout mit. Wir zeigen Ihnen, welche Entscheidungen für Muster und Produktion erforderlich sind.