Torna alle risorse
TecnologiaMay 22, 20266 min read

Come funziona davvero l'integrazione RFID con Hubject (un walkthrough in 5 passi)

Cosa succede tra un tap della card e una sessione di ricarica quando la tua rete fa roaming via Hubject — e i dettagli specifici di UID e provisioning che decidono se il tap va a buon fine.

Come funziona davvero l'integrazione RFID con Hubject (un walkthrough in 5 passi)

Se gestisci una rete Charge Point Operator (CPO) o un e-Mobility Service Provider (eMSP) e vuoi che le card dei tuoi clienti funzionino fuori dal tuo territorio domestico, ti integrerai con Hubject. La maggior parte degli operatori con cui lavoriamo arriva da noi dopo essersi già registrata con Hubject e dopo aver passato ore a fissare la specifica OICP cercando di capire cosa debba fare la card stessa.

Questo è il walkthrough pratico: cosa succede tra un guidatore che tappa la card e una sessione di ricarica che parte, dove si colloca il tuo fornitore di card in quella catena e i dettagli specifici che decidono se il tap va davvero a buon fine.

Il flusso in 5 passi

Quando un tuo guidatore tappa una card RFID a una colonnina in roaming Hubject su una rete CPO diversa dalla tua, ecco cosa accade:

1.Tap della card.: Il guidatore presenta la card al lettore RFID della colonnina. Il lettore estrae l'UID del chip — l'identificativo unico impostato in fabbrica, da 4 o 7 byte a seconda della famiglia di chip.
2.Il CPO invia l'UID a Hubject.: Il backend del CPO ospite non sa a chi appartenga questa card. Impacchetta l'UID in una richiesta OICP AuthorizeStart e la inoltra a Hubject. La richiesta include l'ID del CPO stesso, l'EVSE ID (la colonnina specifica) e l'UID.
3.Hubject inoltra l'UID al tuo backend.: Hubject agisce da clearinghouse: sa che questo UID appartiene al tuo eMSP in base ai mapping OICP EvcoIDs e provider-ID che hai registrato. Inoltra la richiesta di autorizzazione all'endpoint del tuo CPO/eMSP.
4.Il tuo backend autorizza (o rifiuta).: Il tuo backend cerca l'UID nel tuo database utenti, verifica se l'account è in regola, applica eventuali regole tariffarie e restituisce una decisione di autorizzazione — Authorized con il contract ID, oppure NotAuthorized con un reason code.
5.Hubject conferma al CPO.: Il CPO ospite riceve l'autorizzazione, la colonnina si sblocca e la sessione parte. I dati di ricarica e la fatturazione finale vengono regolati attraverso Hubject dopo la fine della sessione.

L'intera catena tipicamente si chiude in meno di un secondo. Quando fallisce, è quasi sempre in uno di due punti: il formato dell'UID sulla tua card non corrisponde a quello atteso dal tuo backend, oppure i mapping provider-ID nel tuo account Hubject non includono il range di chip che stai emettendo.

Cosa deve fare la card stessa

Il compito della card in questo flusso è piccolo ma specifico: presentare un UID che il tuo backend riconosca. Sembra banale finché non inizi a emettere card su più famiglie di chip e ti accorgi che la lunghezza della chiave del tuo database è hard-coded.

Qualche decisione va presa prima della spedizione del primo lotto:

Lunghezza UID.: MIFARE Classic restituisce un UID da 4 byte. Ultralight EV1 e DESFire EV2/EV3 restituiscono UID da 7 byte. La specifica OICP 2.3 di Hubject accetta sia UID da 4 byte sia da 7 byte (oltre a 10 byte), quindi la scelta non ti chiude le porte dell'hub di roaming — ma la colonna del database del tuo backend deve essere abbastanza ampia da memorizzare qualunque formato scelga. Se prevedi di mescolare famiglie di chip in seguito (una card base su Ultralight EV1, una card premium per flotte su DESFire), usa una "VARCHAR(20)" o equivalente e normalizza su stringhe hex.
Mapping UID-cliente.: Quando produciamo un run di produzione, consegniamo un CSV che mappa ogni UID di card a un numero card customer-facing (o ID sequenziale, o qualsiasi campo tu specifichi). Quel mapping è ciò che carichi nel tuo database utenti prima di attivare le card. Senza, dovresti leggere fisicamente ogni card per popolare il DB — improponibile a volumi di produzione. Forniamo questo CSV senza costi aggiuntivi.
Personalizzazione.: Il numero card customer-facing è ciò che il tuo team di customer service chiederà al guidatore di leggere quando chiama. Possiamo incidere a laser o stampare questo numero sulla card stessa. Per la ricarica EV in particolare, l'incisione laser è più duratura della stampa — la card vive in portafogli e tasche per anni.
Pre-configurazione.: Alcuni operatori vogliono che la card venga spedita già con le chiavi crittografiche caricate per un'applicazione specifica. Lo gestiamo nel run di produzione; tu fornisci il materiale chiave e gli application ID, noi li provisioniamo su ogni card prima della personalizzazione. Questo conta più per le implementazioni DESFire che per Ultralight EV1.

Modalità di fallimento comuni (e come evitarle)

Un breve elenco di problemi di integrazione che abbiamo visto:

Il formato UID della card non corrisponde al backend.: Soluzione: conferma 4-byte vs 7-byte prima del primo lotto di produzione, e non fidarti della documentazione — tappa fisicamente un sample sul tuo backend di test prima di emettere l'ordine.
Il range UID non è registrato in Hubject sotto il tuo provider ID.: Soluzione: registra il range UID del chip nel tuo portale Hubject prima del go-live, non dopo.
Round-trip di autorizzazione troppo lento.: Soluzione: il più delle volte è un problema di latenza del backend, non della card. L'handshake card-colonnina è veloce. Se vedi ritardi >3 secondi, profila il tempo di risposta del backend del tuo CPO/eMSP.
I clienti ricevono le card ma queste non compaiono nel database utenti.: Soluzione: carica il CSV UID-cliente nel DB *prima* di spedire le card agli utenti finali. Sembra ovvio; fa inciampare la maggior parte degli operatori al primo lotto.

Cosa specificare quando ordini le card

Se stai per definire un ordine card con noi (o con qualunque fornitore card), la spec sheet che rende indolore l'integrazione con Hubject è questa:

Famiglia di chip (Ultralight EV1 / DESFire — vedi la [nostra guida ai chip](/resources/which-rfid-chip-for-ev-charging/) per la scelta)
Lunghezza UID che vuoi ricevere (legacy 4-byte / standard 7-byte)
Se ti servono applicazioni DESFire pre-provisionate (e il materiale chiave, in tal caso)
Il formato CSV che vuoi per il mapping UID-numero cliente (ordine delle colonne, separatore, encoding)
Se il numero customer-facing va inciso a laser, stampato o entrambi

Azzecca questi cinque elementi e il flusso Hubject diventa un esercizio di configurazione invece che di debugging.

Cosa fare adesso

Se sei nella fase di confronto tra famiglie di chip prima di impegnarti, leggi Quale chip RFID è giusto per la ricarica EV? per l'inquadramento che ti suggeriremmo. Se conosci già il chip e vuoi vederne uno di persona, richiedi un sample pack — spediamo sample Ultralight EV1, DESFire e in PVC riciclato in un'unica spedizione, e il tuo team dev può leggere gli UID nel proprio ambiente di test Hubject prima di qualsiasi impegno.

Oppure dicci cosa stai integrando — preferenza di chip, volume target, hub di roaming, paese di deployment — e torneremo con una spec buildabile e il formato CSV pronto da agganciare al tuo backend.

Share:

Pronto a rendere green la tua rete di ricarica?

Contattaci per scoprire come le nostre card RFID sostenibili possono migliorare la tua infrastruttura di ricarica EV.

Come funziona davvero l'integrazione RFID con Hubject (un walkthrough in 5 passi) | ChargeRFID