Autorisation par badge RFID de recharge en OCPP : le guide complet

Le badge RFID reste le moyen le plus courant de démarrer une session de recharge sur le lieu de travail, au dépôt, à l’hôtel ou en résidence. Le conducteur présente son badge, la borne demande l’autorisation au système central, et la recharge démarre un instant plus tard. Derrière cette expérience simple se cachent un échange de messages OCPP bien défini et une série de choix concernant les règles d’accès, le fonctionnement hors ligne et la sécurité.

Ce guide explique comment fonctionne l’autorisation par badge RFID en OCPP, comment bien gérer les badges, comment les bornes autorisent les conducteurs lorsque la connexion est coupée, pourquoi une autorisation est refusée et quels sont les véritables risques de sécurité. Il compare aussi le RFID aux autres méthodes d’identification.

Comment fonctionne l’autorisation RFID en OCPP

En OCPP 1.6, l’identifiant présenté par le conducteur s’appelle un idTag. Pour un badge RFID, il s’agit généralement de l’UID (identifiant unique) du badge, encodé en chaîne hexadécimale. En OCPP 1.6, un idTag peut compter jusqu’à 20 caractères.

Un échange type se déroule ainsi :

1. Le conducteur présente son badge devant le lecteur de la borne.
2. La borne envoie au CSMS une requête Authorize contenant l’idTag.
3. Le CSMS vérifie le badge au regard de ses règles et renvoie un idTagInfo avec un statut.
4. Si le statut est Accepted et qu’un véhicule est branché, la borne envoie StartTransaction avec le même idTag. Le CSMS renvoie à nouveau un idTagInfo : il peut donc encore refuser la session à ce stade.
5. À la fin, StopTransaction transmet le relevé final du compteur et, si le conducteur a représenté son badge pour arrêter, l’idTag utilisé.

Si un badge figure déjà dans la liste locale ou le cache de la borne, celle-ci peut démarrer sans attendre le CSMS, selon sa configuration. Dans ce cas, un refus ne peut arriver que dans la réponse à StartTransaction, une fois la transaction ouverte.

Les valeurs de statut d’idTagInfo

L’idTagInfo peut aussi contenir une expiryDate, qui indique à la borne combien de temps elle peut conserver le résultat en cache, et un parentIdTag, qui regroupe plusieurs badges. Un usage courant du parentIdTag consiste à permettre à n’importe quel badge d’un même groupe d’arrêter une session.

Ce qui change en OCPP 2.0.1

L’OCPP 2.0.1 remplace l’idTag par l’IdToken, qui contient à la fois une valeur et un type : badge RFID ISO 14443, eMAID pour la recharge sous contrat, ou code clavier, par exemple. Les statuts d’autorisation sont également plus nombreux, si bien qu’un CSMS peut expliquer plus précisément pourquoi un identifiant a été refusé, par exemple parce qu’il n’est pas autorisé sur ce site. La logique de l’échange reste la même.

Bonnes pratiques de gestion des badges

• Enregistrez les badges avant de les distribuer. Saisissez l’UID exactement tel que la borne le lit. Certains lecteurs envoient l’UID dans un ordre d’octets ou un format différent : testez donc un badge sur chaque modèle de borne.
• Attribuez chaque badge à une personne. Les badges anonymes compliquent l’imputation des coûts et la gestion des incidents.
• Associez les conducteurs aux véhicules. Inscrire l’immatriculation dans chaque session simplifie le reporting de flotte.
• Utilisez les bornes autorisées. Limitez chaque conducteur aux sites où il doit recharger.
• Suspendez plutôt que de supprimer. Un badge suspendu ou bloqué conserve son historique et peut être réactivé.
• Passez régulièrement la liste des badges en revue. Retirez l’accès des salariés partis et des badges remplacés.

Dans Üreticy, les badges RFID sont attribués aux conducteurs, peuvent être suspendus ou bloqués à tout moment, et chaque conducteur peut avoir une liste de bornes autorisées et des règles de limite en kWh. Pour une vue plus large des règles conducteurs et véhicules, consultez notre guide de la gestion de la recharge de flotte.

Autorisation hors ligne : liste locale et cache

Une borne qui perd sa connexion Internet doit malgré tout décider si elle laisse un conducteur recharger. L’OCPP propose deux mécanismes pour cela.

Des clés de configuration OCPP 1.6 comme LocalAuthListEnabled, AuthorizationCacheEnabled, LocalAuthorizeOffline et AllowOfflineTxForUnknownId régissent ce comportement. La dernière détermine si un badge inconnu peut recharger lorsque la borne est hors ligne, ce qui revient à arbitrer entre confort du conducteur et maîtrise des coûts. Les transactions réalisées hors ligne sont transmises au CSMS au retour de la connexion.

Un risque concret : un badge bloqué dans le CSMS peut continuer à fonctionner hors ligne s’il reste dans le cache ou la liste locale. Après avoir bloqué un badge sensible, mettez à jour la liste locale et envisagez de vider le cache des bornes concernées.

Motifs de refus courants et comment les traiter

Pour le conducteur, tous les refus se ressemblent : la borne ne démarre pas. Pour l’opérateur, le motif compte : un bon CSMS enregistre donc chaque refus avec sa cause. Üreticy liste chaque autorisation refusée avec un motif, comme un badge inconnu, une limite atteinte, une borne non autorisée ou un badge bloqué.

• Badge inconnu : vérifiez que le badge est enregistré et que le format de l’UID correspond à ce qu’envoie le lecteur.
• Limite atteinte : le conducteur a épuisé son quota kWh. Expliquez la règle, ou ajustez la limite si elle est trop basse.
• Borne non autorisée : le conducteur n’est pas autorisé sur ce site. Confirmez que c’est bien voulu.
• Badge bloqué : vérifiez le statut du badge auprès de l’administrateur, surtout si le conducteur l’a déclaré perdu.
• Problèmes de lecteur : si aucune demande d’autorisation n’arrive, le lecteur est peut-être défaillant. Une erreur ReaderFailure dans StatusNotification indique un problème matériel ; consultez notre guide des codes d’erreur OCPP.

Enjeux de sécurité

La plupart des bornes OCPP ne lisent que l’UID du badge RFID et l’envoient comme idTag. Or l’UID n’est pas secret : avec des outils largement disponibles, il peut être lu puis copié sur un autre badge. Un badge RFID de base identifie donc un utilisateur, mais ne l’authentifie pas de manière forte.

Mesures concrètes pour limiter le risque :

• Fixez des limites kWh strictes pour qu’un badge copié ne puisse pas consommer une énergie illimitée.
• Limitez les badges à des bornes autorisées pour réduire la zone où un badge copié fonctionne.
• Surveillez les refus ConcurrentTx et les sessions à des heures ou des lieux inhabituels, qui peuvent révéler un badge dupliqué.
• Bloquez immédiatement les badges perdus et mettez à jour les listes hors ligne.
• Utilisez TLS (wss://) entre la borne et le CSMS pour que les identifiants ne circulent pas en clair sur le réseau.

Il existe des badges dotés de fonctions cryptographiques, mais ils n’apportent un bénéfice que si le lecteur de la borne vérifie ces fonctions. Demandez au fabricant ce que le lecteur contrôle réellement.

Les alternatives au badge RFID

• Application mobile : le conducteur démarre la session depuis une application, et le CSMS envoie une commande de démarrage à distance à la borne.
• QR code : un code apposé sur la borne ouvre une page web ou une application pour ce connecteur. Üreticy génère des étiquettes QR code prêtes à imprimer pour chaque connecteur.
• Plug & Charge (ISO 15118) : le véhicule s’authentifie avec des certificats numériques au branchement du câble. Cette méthode allie sécurité forte et grand confort, mais nécessite des véhicules, des bornes et une infrastructure de certificats compatibles. Le Plug & Charge figure sur la feuille de route d’Üreticy.

Le RFID reste un bon choix lorsque les utilisateurs sont connus et que les badges sont gérés de façon centralisée.

Questions fréquentes

Gérez badges RFID, conducteurs et motifs de refus pour toutes vos bornes OCPP dans un seul tableau de bord. Découvrez la plateforme OCPP Üreticy ou consultez la liste complète des fonctionnalités.