Zurück zu Ressourcen
TechnologieMay 22, 20265 min read

Wie die Hubject-RFID-Integration tatsächlich funktioniert (eine 5-Schritte-Anleitung)

Was zwischen einem Karten-Tap und einer Ladesitzung passiert, wenn Ihr Netzwerk über Hubject roamt – und die spezifischen UID- und Provisionierungs-Details, die darüber entscheiden, ob der Tap gelingt.

Wie die Hubject-RFID-Integration tatsächlich funktioniert (eine 5-Schritte-Anleitung)

Wenn Sie ein Charge Point Operator (CPO) Netzwerk oder einen e-Mobility Service Provider (eMSP) betreiben und möchten, dass die Karten Ihrer Kunden außerhalb Ihres Heimatgebiets funktionieren, werden Sie mit Hubject integrieren. Die meisten Betreiber, mit denen wir arbeiten, kommen zu uns, nachdem sie sich bereits bei Hubject angemeldet haben und jetzt vor der OICP-Spezifikation sitzen und versuchen herauszufinden, was die Karte selbst leisten muss.

Dies ist die praktische Anleitung: Was zwischen einem Fahrer, der seine Karte tapt, und dem Start einer Ladesitzung passiert, wo Ihr Kartenlieferant in dieser Kette steht und die spezifischen Details, die darüber entscheiden, ob der Tap tatsächlich gelingt.

Der 5-Schritte-Ablauf

Wenn einer Ihrer Fahrer eine RFID-Karte an einem Hubject-Roaming-Lader im Netzwerk eines anderen CPOs tappt, passiert Folgendes:

1.Karten-Tap.: Der Fahrer präsentiert die Karte am RFID-Leser des Laders. Der Leser zieht die UID des Chips – die werkseitig festgelegte eindeutige Kennung, 4 oder 7 Byte je nach Chipfamilie.
2.Der CPO sendet die UID an Hubject.: Das Backend des Host-CPOs weiß nicht, zu wem diese Karte gehört. Es verpackt die UID in eine OICP-AuthorizeStart-Anfrage und leitet sie an Hubject weiter. Die Anfrage enthält die ID des CPOs, die EVSE-ID (den spezifischen Ladepunkt) und die UID.
3.Hubject leitet die UID an Ihr Backend weiter.: Hubject agiert als Clearingstelle: Es weiß auf Basis der OICP-EvcoIDs und Anbieter-ID-Zuordnungen, die Sie registriert haben, dass diese UID zu Ihrem eMSP gehört. Es leitet die Autorisierungsanfrage an Ihren CPO/eMSP-Endpunkt weiter.
4.Ihr Backend autorisiert (oder lehnt ab).: Ihr Backend sucht die UID in Ihrer Nutzerdatenbank, prüft, ob das Konto in Ordnung ist, wendet optional Tarifregeln an und gibt eine Autorisierungsentscheidung zurück – Authorized mit der Vertrags-ID oder NotAuthorized mit einem Grundcode.
5.Hubject bestätigt zurück an den CPO.: Der Host-CPO erhält die Autorisierung, der Lader entriegelt, und die Sitzung beginnt. Ladedaten und Endabrechnung werden nach Sitzungsende über Hubject abgewickelt.

Die gesamte Kette läuft typischerweise in unter einer Sekunde durch. Wenn sie fehlschlägt, dann fast immer an einem von zwei Punkten: Das UID-Format auf Ihrer Karte stimmt nicht mit dem überein, was Ihr Backend erwartet, oder die Anbieter-ID-Zuordnungen in Ihrem Hubject-Konto enthalten den Chip-Bereich nicht, den Sie ausgeben.

Was die Karte selbst leisten muss

Die Aufgabe der Karte in diesem Ablauf ist klein, aber spezifisch: eine UID präsentieren, die Ihr Backend erkennt. Das klingt trivial, bis Sie anfangen, Karten über mehrere Chipfamilien hinweg auszugeben, und merken, dass die Schlüssellänge Ihrer Datenbank fest verdrahtet ist.

Ein paar Entscheidungen müssen getroffen werden, bevor die erste Charge ausgeliefert wird:

UID-Länge.: MIFARE Classic gibt eine 4-Byte-UID zurück. Ultralight EV1 und DESFire EV2/EV3 geben 7-Byte-UIDs zurück. Die OICP 2.3 Spezifikation von Hubject akzeptiert sowohl 4-Byte- als auch 7-Byte-UIDs (und auch 10-Byte), die Wahl sperrt Sie also nicht aus dem Roaming-Hub aus – aber die Spalte in Ihrer eigenen Backend-Datenbank muss breit genug sein, um das von Ihnen gewählte Format zu speichern. Wenn Sie später Chipfamilien mischen könnten (eine Basiskarte auf Ultralight EV1, eine Premium-Flottenkarte auf DESFire), verwenden Sie ein VARCHAR(20) oder Äquivalent und normalisieren Sie auf Hex-Strings.
UID-zu-Kunden-Zuordnung.: Wenn wir einen Produktionslauf fertigen, übergeben wir eine CSV, die die UID jeder Karte einer kundengerichteten Kartennummer (oder fortlaufenden ID, oder einem beliebigen von Ihnen angegebenen Feld) zuordnet. Diese Zuordnung wird in Ihre Nutzerdatenbank geladen, bevor die Karten aktiviert werden. Ohne sie müssten Sie jede Karte physisch auslesen, um Ihre DB zu befüllen – bei Produktionsvolumen ein No-Go. Wir liefern diese CSV ohne Aufpreis.
Personalisierung.: Die kundengerichtete Kartennummer ist das, was Ihr Kundenservice den Fahrer beim Anruf vorlesen lassen wird. Wir können diese Nummer auf der Karte lasern oder drucken. Für EV-Laden speziell ist Lasergravur haltbarer als Druck – die Karte lebt jahrelang in Geldbeuteln und Taschen.
Vorkonfiguration.: Manche Betreiber möchten, dass die Karte bereits mit kryptografischen Schlüsseln für eine spezifische Anwendung geladen geliefert wird. Wir handhaben das im Produktionslauf; Sie liefern das Schlüsselmaterial und die Anwendungs-IDs, wir provisionieren sie vor der Personalisierung auf jeder Karte. Das ist für DESFire-Rollouts relevanter als für Ultralight EV1.

Häufige Fehlerszenarien (und wie man sie vermeidet)

Eine kurze Liste der Integrationsprobleme, die wir gesehen haben:

Das UID-Format der Karte stimmt nicht mit dem Backend überein.: Lösung: Bestätigen Sie 4-Byte vs. 7-Byte vor der ersten Produktionscharge und vertrauen Sie nicht der Dokumentation – tappen Sie ein Muster physisch auf Ihrem Test-Backend, bevor Sie bestellen.
Der UID-Bereich ist nicht unter Ihrer Anbieter-ID bei Hubject registriert.: Lösung: Registrieren Sie den Chip-UID-Bereich in Ihrem Hubject-Portal, bevor Sie live gehen, nicht danach.
Authorize-Roundtrip zu langsam.: Lösung: Meistens ist das ein Backend-Latenzproblem, kein Kartenproblem. Der Karten-zu-Lader-Handshake ist schnell. Wenn Sie >3 Sekunden Verzögerung sehen, profilieren Sie die Antwortzeit Ihres CPO/eMSP-Backends.
Kunden erhalten Karten, aber sie tauchen nicht in der Nutzerdatenbank auf.: Lösung: Laden Sie die UID-zu-Kunden-CSV in Ihre DB, *bevor* Sie Karten an Endnutzer versenden. Klingt offensichtlich; bringt die meisten Betreiber beim ersten Mal zum Stolpern.

Was Sie beim Kartenauftrag spezifizieren sollten

Wenn Sie kurz davor stehen, einen Kartenauftrag mit uns (oder einem beliebigen Kartenlieferanten) zu spezifizieren, sieht das Spec-Sheet, das die Hubject-Integration schmerzfrei macht, so aus:

Chipfamilie (Ultralight EV1 / DESFire – siehe [unseren Chip-Leitfaden](/resources/which-rfid-chip-for-ev-charging/) für die Wahl)
UID-Länge, die Sie zurückbekommen möchten (4-Byte Legacy / 7-Byte Standard)
Ob Sie DESFire-Anwendungen vorprovisioniert benötigen (und das Schlüsselmaterial, falls ja)
Das CSV-Format, das Sie für die UID-zu-Kundennummer-Zuordnung möchten (Spaltenreihenfolge, Trenner, Codierung)
Ob die kundengerichtete Nummer lasergraviert, gedruckt oder beides sein soll

Wenn Sie diese fünf Dinge richtig haben, wird der Hubject-Ablauf zu einer Konfigurationsübung statt zu einer Debugging-Übung.

Was als Nächstes tun

Wenn Sie auf der Stufe sind, Chipfamilien zu vergleichen, bevor Sie sich festlegen, lesen Sie Welcher RFID-Chip ist der richtige für EV-Laden? für den Rahmen, den wir vorschlagen würden. Wenn Sie den Chip bereits kennen und einen in Person sehen möchten, fordern Sie ein Musterpaket an – wir versenden Ultralight EV1, DESFire und recycelte PVC-Muster in einem Versand, und Ihr Dev-Team kann die UIDs in Ihre Hubject-Testumgebung einlesen, bevor irgendeine Verpflichtung eingegangen wird.

Oder erzählen Sie uns, was Sie integrieren – Chip-Präferenz, Zielvolumen, Roaming-Hub, Rollout-Land – und wir kommen mit einer umsetzbaren Spezifikation und dem CSV-Format zurück, bereit zum Drop in Ihr Backend.

Share:

Bereit, Ihr Ladenetz nachhaltig zu gestalten?

Kontaktieren Sie uns, um zu erfahren, wie unsere nachhaltigen RFID-Karten Ihre Ladeinfrastruktur verbessern können.

Wie die Hubject-RFID-Integration tatsächlich funktioniert (eine 5-Schritte-Anleitung) | ChargeRFID