Sessions de recharge échouées : le diagnostic depuis la supervision

Une borne affichée disponible dans la supervision peut refuser des sessions toute la journée. À l'inverse, une borne qui remonte une erreur peut fonctionner, le défaut venant du véhicule. Analyser les sessions échouées sert à faire la différence avant d'engager un déplacement. Cette méthode s'appuie sur la spécification OCPP 1.6 et sur le livre blanc de l'Open Charge Alliance consacré à la disponibilité.

Ce qu'est une session échouée

L'OCA le rappelle : une session réussie mobilise toute une chaîne, la borne, le système central qui autorise et suit la session, des tiers comme l'opérateur de mobilité ou l'application, et le véhicule lui-même. Un échec peut venir de chacun de ces maillons. Le tri consiste à l'attribuer au bon.

Trois signaux sont à croiser dans la supervision :

• une session démarrée puis arrêtée très vite, avec peu ou pas d'énergie ;
• une tentative sans session : autorisation refusée, ou connecteur passé en Preparing puis revenu en Available sans charge ;
• une session longue mais anormale, par exemple bloquée en SuspendedEVSE.

Le motif d'arrêt transmis en fin de transaction (champ reason de StopTransaction) oriente déjà le diagnostic : EVDisconnected, PowerLoss, EmergencyStop, Reboot ou DeAuthorized n'appellent pas la même réponse.

Lire les statuts OCPP : Faulted, SuspendedEV, SuspendedEVSE

En OCPP 1.6, chaque connecteur remonte son statut par StatusNotification. La spécification range Unavailable et Faulted parmi les états inopérants. Tous les autres, y compris les deux états suspendus, sont considérés comme opérationnels.

Deux précisions de la spécification évitent de fausses alertes. Si la charge est suspendue à la fois par le véhicule et par la borne, SuspendedEVSE l'emporte. Et au démarrage d'une transaction, un bref passage par SuspendedEV ou SuspendedEVSE entre Preparing et Charging est normal, parfois en quelques secondes. Une alerte sur ces états doit donc porter sur leur durée, pas sur leur apparition.

Les codes ErrorCode de StatusNotification

Le champ errorCode de StatusNotification prend l'une des seize valeurs définies par OCPP 1.6. Quand le statut n'est pas Faulted, la condition est à traiter comme un avertissement : la charge reste possible. Les champs libres info et vendorErrorCode portent le code du fabricant, souvent décisif, notice en main.

Limite connue, signalée par l'OCA : StatusNotification gère mal les erreurs multiples. Quand deux erreurs arrivent l'une après l'autre, rien n'indique si la première est toujours active. La supervision peut alors demander un état à jour par TriggerMessage. L'OCA conseille aussi de vérifier avec le fabricant que la borne exploite vraiment ces codes plutôt que de tout remonter en OtherError. En OCPP 2.0.1, errorCode disparaît de StatusNotification et les erreurs passent par des événements rattachés à chaque composant (voir OCPP 1.6 et 2.0.1).

Autorisations refusées : borne ou système central ?

Un refus d'autorisation n'est pas une panne de borne. Il est décidé par le système central, et une carte inconnue ou expirée doit être refusée. En OCPP 1.6, la réponse porte l'un de ces statuts : Accepted, Blocked (identifiant bloqué), Expired (expiré), Invalid (inconnu) ou ConcurrentTx (déjà engagé dans une autre transaction).

Ce qui doit alerter, c'est la répétition. Des refus de badges différents sur un même site, ou concentrés sur les cartes d'un même opérateur de mobilité, pointent vers une liste d'autorisation périmée ou une interface d'itinérance en panne. L'OCA recommande justement de contrôler la santé des interfaces avec les tiers quand les refus se multiplient.

Deux réglages de la borne méritent un contrôle : le cache d'autorisation et la liste locale, qui permettent d'accepter des badges connus quand la borne est hors connexion. Des échecs limités aux coupures du réseau mobile relèvent souvent de là. Attention enfin : selon l'OCA, une borne OCPP 1.6 qui revient en ligne ne transmet pas ses tentatives d'autorisation refusées pendant la coupure, seuls les messages liés aux transactions sont conservés.

Dialogue borne et véhicule : IEC 61851 et ISO 15118

Avant de délivrer de l'énergie, la borne et le véhicule échangent. D'après l'OCA, ce dialogue repose sur le protocole du mode 3 en courant alternatif, et sur ISO 15118 ou DIN en courant continu. En courant alternatif, la borne indique au véhicule le courant maximal disponible par le signal pilote (Control Pilot), défini par la norme IEC 61851-1, rappelle la spécification OCPP 1.6. Celle-ci ne prend pas en charge les messages ISO 15118 : l'OCA propose une note d'application pour y ajouter le Plug and Charge. Côté réglementation, le règlement délégué (UE) 2025/656 impose la conformité aux parties 1 à 5 de la norme EN ISO 15118 pour les points ouverts au public installés ou rénovés à partir du 8 janvier 2026, puis à la partie 15118-20 à partir du 1er janvier 2027.

Un échec à cette étape remonte en EVCommunicationError. La spécification précise que ce n'est pas une vraie erreur : la borne n'a pas à passer en Faulted, et ce code ne s'emploie qu'avec les statuts Preparing, SuspendedEV, SuspendedEVSE et Finishing. L'OCA ajoute que l'erreur peut venir du véhicule, et ne devrait alors pas compter comme indisponibilité. La méthode est donc comparative :

• un même véhicule en échec sur plusieurs bornes : la piste véhicule est la plus probable ;
• plusieurs véhicules en échec sur la même borne : la borne, son câble ou son connecteur sont suspects ;
• des échecs sur un seul modèle de véhicule après une mise à jour du firmware de la borne : interroger le fabricant.

Sur une borne DC, l'OCA range dans la même catégorie l'échec de la phase initiale d'échange, test d'isolement compris. Un test d'isolement qui échoue avec tous les véhicules justifie un déplacement.

Méthode de tri et envoi d'un technicien

Le tri suit un ordre, du moins coûteux au plus coûteux :

• Étape 1, la borne est-elle joignable ? Une absence de Heartbeat ou une rupture de la liaison WebSocket signale une coupure d'alimentation ou de communication. Au retour, un nouveau BootNotification trahit un redémarrage.
• Étape 2, le statut est-il inopérant ? Pour Faulted ou Unavailable, lire errorCode, vendorErrorCode et l'historique de la borne.
• Étape 3, l'échec tient-il à l'autorisation ? Contrôler les réponses et les interfaces tierces.
• Étape 4, l'échec suit-il un véhicule ou une borne ? Appliquer la comparaison ci-dessus.
• Étape 5, une action à distance est-elle possible ? En OCPP 1.6 : Reset, UnlockConnector, TriggerMessage, GetDiagnostics pour récupérer le journal, UpdateFirmware.

Le délai compte aussi pour l'information des conducteurs : pour une infrastructure ouverte au public et supervisée, l'article R353-4-5 du code de l'énergie impose de mettre à disposition de tous les utilisateurs une information sur l'indisponibilité dès qu'un incident affecte l'usage de l'infrastructure plus de deux heures.

Le déplacement s'impose quand le défaut touche la sécurité ou la mesure (GroundFailure, OverCurrentFailure répétés, PowerMeterFailure, PowerSwitchFailure), en cas de dommage physique, pour lequel OCPP n'a pas de code dédié selon l'OCA, ou quand les actions à distance n'ont rien changé. Mesurez ensuite : l'OCA recommande de calculer la disponibilité par point de recharge plutôt que par borne ou par site (voir nos articles sur le taux de disponibilité et sur les indicateurs de maintenance (MTTR, MTBF)). Pour une borne isolée sans contrat, un dépannage ponctuel d'une borne reste possible.

Ce que JCSM prend en charge

La supervision fait partie de notre offre d'exploitation : nous suivons les statuts et codes d'erreur de parcs multi-marques, nous trions les sessions échouées et nous tentons d'abord les actions à distance. Quand un déplacement s'impose, le technicien part avec le diagnostic. Le détail est sur notre page supervision.

Questions fréquentes