Retour aux ressources
TechnologieMay 22, 20266 min read

Comment fonctionne réellement l'intégration RFID Hubject (en 5 étapes)

Ce qui se passe entre la présentation d'une carte et le démarrage d'une session de recharge lorsque votre réseau itinère via Hubject – et les détails précis d'UID et d'approvisionnement qui déterminent si le tap aboutit.

Comment fonctionne réellement l'intégration RFID Hubject (en 5 étapes)

Si vous exploitez un réseau de Charge Point Operator (CPO) ou d'e-Mobility Service Provider (eMSP) et que vous souhaitez que les cartes de vos clients fonctionnent hors de votre territoire d'origine, vous allez vous intégrer avec Hubject. La plupart des opérateurs avec lesquels nous travaillons viennent nous voir après avoir déjà signé avec Hubject et se retrouvent à scruter la spécification OICP en se demandant ce que la carte elle-même doit faire.

Voici la marche à suivre pratique : ce qui se passe entre la présentation par le conducteur de sa carte et le démarrage d'une session de recharge, où se situe votre fournisseur de cartes dans cette chaîne, et les détails précis qui déterminent si le tap aboutit réellement.

Le déroulé en 5 étapes

Lorsqu'un de vos conducteurs présente une carte RFID à une borne en itinérance Hubject sur le réseau d'un autre CPO, voici ce qui se passe :

1.Présentation de la carte.: Le conducteur présente la carte au lecteur RFID du chargeur. Le lecteur extrait l'UID de la puce – l'identifiant unique défini en usine, de 4 ou 7 octets selon la famille.
2.Le CPO envoie l'UID à Hubject.: Le backend du CPO hôte ne sait pas à qui appartient cette carte. Il encapsule l'UID dans une requête OICP AuthorizeStart et la transmet à Hubject. La requête inclut l'identifiant du CPO, l'EVSE ID (le chargeur précis) et l'UID.
3.Hubject transmet l'UID à votre backend.: Hubject agit comme chambre de compensation : il sait que cet UID appartient à votre eMSP grâce aux EvcoIDs OICP et aux mappings d'identifiant fournisseur que vous avez enregistrés. Il transmet la demande d'autorisation à votre point de terminaison CPO/eMSP.
4.Votre backend autorise (ou refuse).: Votre backend recherche l'UID dans votre base utilisateur, vérifie que le compte est en règle, applique optionnellement des règles de tarif et renvoie une décision d'autorisation – Authorized avec l'identifiant de contrat, ou NotAuthorized avec un code motif.
5.Hubject confirme au CPO.: Le CPO hôte reçoit l'autorisation, la borne se déverrouille et la session démarre. Les données de charge et la facturation finale se règlent via Hubject après la fin de la session.

L'ensemble de la chaîne s'exécute généralement en moins d'une seconde. Lorsqu'elle échoue, c'est presque toujours à l'un de ces deux points : le format d'UID de votre carte ne correspond pas à ce qu'attend votre backend, ou les mappings d'identifiant fournisseur dans votre compte Hubject n'incluent pas la plage de puces que vous émettez.

Ce que la carte elle-même doit faire

Le rôle de la carte dans ce flux est limité mais précis : présenter un UID que votre backend reconnaîtra. Cela semble trivial jusqu'à ce que vous émettiez sur plusieurs familles de puces et constatiez que la longueur de clé de votre base est codée en dur.

Quelques décisions doivent être prises avant l'expédition du premier lot :

Longueur d'UID.: MIFARE Classic renvoie un UID de 4 octets. Ultralight EV1 et DESFire EV2/EV3 renvoient des UID de 7 octets. La spécification OICP 2.3 de Hubject accepte les deux (et aussi 10 octets), donc le choix ne vous exclut pas du hub d'itinérance – mais la colonne de votre base doit être assez large pour stocker le format retenu. Si vous prévoyez de mélanger plus tard les familles (une carte de base en Ultralight EV1, une carte de flotte premium en DESFire), utilisez un VARCHAR(20) ou équivalent et normalisez en chaînes hex.
Mapping UID-vers-client.: Lorsque nous produisons une série, nous remettons un CSV qui associe chaque UID de carte à un numéro de carte côté client (ou un identifiant séquentiel, ou tout champ que vous spécifiez). Ce mapping est ce que vous chargez dans votre base utilisateur avant d'activer les cartes. Sans lui, il faudrait lire physiquement chaque carte pour peupler votre base – impossible aux volumes de production. Nous fournissons ce CSV sans surcoût.
Personnalisation.: Le numéro de carte côté client est ce que votre service client demandera au conducteur de lire au téléphone. Nous pouvons graver au laser ou imprimer ce numéro sur la carte. Pour la recharge VE en particulier, la gravure laser est plus durable que l'impression – la carte vit dans des portefeuilles et des poches pendant des années.
Pré-configuration.: Certains opérateurs souhaitent que la carte soit livrée avec les clés cryptographiques déjà chargées pour une application spécifique. Nous gérons cela en production : vous fournissez le matériel de clés et les AID, nous les provisionnons sur chaque carte avant la personnalisation. Cela compte davantage pour les déploiements DESFire que pour Ultralight EV1.

Modes d'échec courants (et comment les éviter)

Une courte liste de problèmes d'intégration que nous avons vus :

Le format d'UID de la carte ne correspond pas au backend.: Solution : confirmez 4 octets vs 7 octets avant le premier lot de production, et ne faites pas confiance à la documentation – présentez physiquement un échantillon à votre backend de test avant de passer commande.
La plage d'UID n'est pas enregistrée auprès de Hubject sous votre identifiant fournisseur.: Solution : enregistrez la plage d'UID dans votre portail Hubject avant la mise en service, pas après.
Aller-retour d'autorisation trop lent.: Solution : c'est le plus souvent une latence backend, pas un problème de carte. La poignée de main carte-vers-borne est rapide. Si vous observez des délais supérieurs à 3 secondes, profilez le temps de réponse de votre backend CPO/eMSP.
Les clients reçoivent leurs cartes mais elles n'apparaissent pas dans la base utilisateur.: Solution : chargez le CSV UID-vers-client dans votre base *avant* d'expédier les cartes. Cela semble évident ; cela piège la plupart des opérateurs sur leur premier lot.

Ce qu'il faut spécifier à la commande

Si vous êtes sur le point de cadrer une commande de cartes avec nous (ou avec n'importe quel fournisseur), la fiche de spécification qui rend l'intégration Hubject indolore ressemble à ceci :

Famille de puces (Ultralight EV1 / DESFire – voir [notre guide des puces](/resources/which-rfid-chip-for-ev-charging/) pour le choix)
Longueur d'UID souhaitée en retour (4 octets historique / 7 octets standard)
Besoin éventuel d'applications DESFire pré-provisionnées (et le matériel de clés, le cas échéant)
Le format CSV souhaité pour le mapping UID-vers-numéro-client (ordre des colonnes, séparateur, encodage)
Si le numéro côté client doit être gravé au laser, imprimé, ou les deux

Réussissez ces cinq éléments et le flux Hubject devient un exercice de configuration plutôt qu'un exercice de débogage.

Ce qu'il faut faire ensuite

Si vous êtes au stade de comparer les familles de puces avant de vous engager, lisez Quelle puce RFID choisir pour la recharge VE ? pour le cadrage que nous suggérerions. Si vous savez déjà quelle puce et souhaitez en voir une physiquement, demandez un pack d'échantillons – nous livrons Ultralight EV1, DESFire et PVC recyclé en une seule expédition, et votre équipe de développement peut lire les UID dans votre environnement de test Hubject avant tout engagement.

Ou dites-nous ce que vous intégrez – préférence de puce, volume cible, hub d'itinérance, pays de déploiement – et nous reviendrons avec une spécification réalisable et le format CSV prêt à être injecté dans votre backend.

Share:

Prêt à rendre votre réseau de recharge plus vert ?

Contactez-nous pour découvrir comment nos cartes RFID durables peuvent améliorer votre infrastructure de recharge.

Comment fonctionne réellement l'intégration RFID Hubject (en 5 étapes) | ChargeRFID