Lorsqu'un conducteur présente son badge RFID, la borne réfléchit un instant, puis allume un voyant vert ou rouge. Pendant ce court instant, la borne demande au logiciel de gestion, via un message Authorize : « Ce badge peut-il démarrer une recharge ? » Cet article explique le déroulement d'Authorize, les réponses possibles et les problèmes les plus fréquents sur le terrain.

Le déroulement d'Authorize

  1. L'utilisateur présente son badge ; la borne lit son identifiant (UID).
  2. La borne envoie cet identifiant au CSMS sous forme d'idTag dans un message Authorize.
  3. Le CSMS vérifie si le badge est enregistré et valide, si l'utilisateur est autorisé sur cette station et quelles sont ses limites.
  4. La réponse revient avec un statut dans idTagInfo.
  5. Si le statut est Accepted, la borne se prépare à démarrer la recharge.

Exemple :

[2, "3001", "Authorize", {"idTag": "04A2B3C4D5E6F7"}] [3, "3001", {"idTagInfo": {"status": "Accepted", "expiryDate": "2027-01-01T00:00:00Z"}}]

Valeurs de statut possibles

En OCPP 1.6J, idTagInfo.status prend l'une de ces valeurs :

  • Accepted : le badge est valide, la recharge peut démarrer.
  • Blocked : le badge est bloqué (par exemple après une déclaration de perte).
  • Expired : la validité du badge a expiré.
  • Invalid : le badge n'est pas reconnu.
  • ConcurrentTx : ce badge est déjà utilisé dans une autre transaction de recharge.

La réponse peut aussi contenir expiryDate et parentIdTag. parentIdTag sert dans des scénarios où des badges d'un même groupe peuvent arrêter les transactions les uns des autres ; voir idTag et parentIdTag.

En OCPP 2.0.1 et 2.1, la structure est similaire, mais les champs s'appellent idToken et idTokenInfo. Le type d'identifiant (ISO14443, eMAID, KeyCode, Central, etc.) est précisé séparément et la liste des statuts est élargie (par exemple NoCredit, NotAllowedTypeEVSE, NotAtThisLocation, NotAtThisTime).

Authorize est-il toujours nécessaire ?

Non. Authorize peut être omis dans certains cas :

  • Démarrage à distance : lorsque l'utilisateur démarre la recharge depuis une application mobile, le CSMS envoie RemoteStartTransaction. Le fait que la borne refasse ou non une autorisation dépend du paramètre AuthorizeRemoteTxRequests. Voir AuthorizeRemoteTxRequests.
  • Liste locale et cache : si la borne trouve le badge valide dans sa liste locale ou son cache, elle peut, selon ses paramètres, démarrer sans interroger le CSMS.
  • Mode libre : certaines installations privées peuvent être configurées pour une recharge automatique sans badge.

Que se passe-t-il hors ligne ?

Lorsque internet est coupé, la borne ne peut pas interroger le CSMS. Le comportement dépend alors des paramètres :

  • Si LocalAuthorizeOffline = true, la borne peut démarrer la recharge pour les badges valides dans la liste locale ou le cache.
  • Si AllowOfflineTxForUnknownId = true, la recharge peut démarrer même avec des badges inconnus (paramètre risqué).
  • Sinon, aucune recharge ne peut démarrer hors ligne.

Voir notre article LocalAuthorizeOffline et recharge hors ligne.

Problèmes fréquents

  • Le badge est enregistré dans le tableau de bord mais renvoie Invalid : l'UID est peut-être lu dans un autre format (ordre des octets inversé, zéros initiaux manquants, etc.). L'idTag des journaux de la borne doit correspondre exactement à l'enregistrement du tableau de bord.
  • Le badge fonctionne et la recharge démarre alors que la limite est épuisée : le contrôle de limite doit se faire lors d'Authorize. Dans Üreticy, le badge d'un conducteur ayant épuisé sa limite est refusé dès l'étape Authorize et le motif est enregistré.
  • Réponses lentes : si la connexion mobile est lente, le conducteur attend quelques secondes. Un cache local réduit ce délai.

Nous traitons tous les aspects de l'autorisation par badge dans notre guide sur l'autorisation par badge RFID en OCPP.

Les identifiants autres que les badges

Authorize ne se limite pas aux badges RFID. Pour les sessions lancées depuis une application mobile ou un QR code, le CSMS transmet à la borne un identifiant propre à l'utilisateur avec la demande de démarrage à distance. Dans les scénarios Plug & Charge, le véhicule s'identifie avec un certificat ISO 15118 et, en OCPP 2.0.1/2.1, cette identité est validée comme un idToken de type eMAID. Certaines bornes permettent aussi la saisie d'un code PIN sur leur clavier. Quelle que soit la méthode, les règles côté CSMS doivent être les mêmes : qui peut recharger, sur quelle station, avec quelles limites. Cette cohérence garantit la même expérience au conducteur, quelle que soit la méthode choisie.

Conclusion

Authorize est la porte qui décide qui peut accéder au réseau de recharge. Des codes de réponse corrects, un comportement hors ligne bien pensé et des enregistrements de badges cohérents améliorent à la fois la sécurité et la satisfaction des conducteurs. Le logiciel OCPP d'Üreticy vous permet d'attribuer des badges aux conducteurs, de les bloquer et de voir chaque refus avec son motif.