Indicateurs de maintenance des bornes : MTTR, MTBF et sessions réussies

Un tableau de bord de maintenance ne vaut que par la définition de ses indicateurs. Deux prestataires peuvent afficher le même « MTTR » en mesurant deux choses différentes : l'un compte à partir de l'alerte, l'autre à partir de l'arrivée du technicien. Cet article pose des définitions utilisables dans un contrat, montre comment les calculer depuis les messages OCPP et liste les erreurs de calcul les plus fréquentes. Le calcul du taux de disponibilité lui-même et les leviers pour l'améliorer sont traités dans notre article sur le taux de disponibilité des bornes IRVE.

Partir d'un vocabulaire commun : la NF EN 13306

La terminologie de la maintenance est normalisée. La norme NF EN 13306, dans son édition de novembre 2017 en vigueur, présente les termes généraux et leurs définitions pour les aspects techniques, administratifs et de management de la maintenance. C'est la référence à citer dans un contrat ou un cahier des charges pour que l'exploitant, le mainteneur et le fabricant donnent le même sens aux mots qu'ils emploient.

Les acronymes anglais (MTTA, MTTR, MTBF) circulent dans tous les logiciels de supervision avec des définitions variables. Les formules ci-dessous sont des définitions d'usage. Avant de les rendre contractuelles, vérifiez leur cohérence avec la norme et écrivez noir sur blanc l'événement qui ouvre et celui qui ferme chaque compteur. Pour le MTTR, nous retenons la définition de l'IEC 60050-192, entrée 192-07-23 : le temps moyen de rétablissement (mean time to restoration), délais compris, du début de l'indisponibilité au retour à l'état disponible.

Six indicateurs et leur définition opérationnelle

MTTR et temps d'intervention sont souvent confondus. Le premier court du début de l'indisponibilité au retour à l'état disponible : il ajoute au travail du mainteneur le délai de détection, la qualification, l'attente d'une pièce ou d'un accès au site. Le second ne mesure que le travail du mainteneur. C'est le MTTR que subit le conducteur et c'est lui qui pèse sur la disponibilité. Suivre les deux montre où se perd le temps : dans la détection, dans la logistique ou dans la réparation.

Le MTBF se calcule comme le temps de fonctionnement cumulé divisé par le nombre de défaillances sur la période. Il n'a de sens que par modèle de borne, voire par version de firmware : agrégé sur un parc hétérogène, il masque le modèle qui tombe en panne chaque semaine.

Le taux de sessions réussies est le plus parlant pour l'usager et le plus difficile à attribuer. Le livre blanc de l'Open Charge Alliance (OCA) Improving uptime monitoring with OCPP le rappelle : une session mobilise la borne, le système central, les partenaires d'itinérance et le véhicule. Un refus d'autorisation peut être légitime, avec un badge expiré, ou anormal, avec une liste de badges périmée ou une liaison coupée avec l'opérateur de mobilité.

Disponibilité : ce que dit l'AFIR, et ce qu'il ne dit pas

Le texte du règlement (UE) 2023/1804, dit AFIR, ne fixe pas de taux de disponibilité minimal. Son article 20 impose en revanche aux exploitants de points de recharge ouverts au public de rendre disponibles des données dynamiques, dont « le statut opérationnel (opérationnel/hors service) » et « la disponibilité (en cours d'utilisation/libre) ». Au sens de l'AFIR, la disponibilité est donc un état publié à l'instant, pas un pourcentage sur une période. Le détail des obligations figure dans notre article sur le règlement AFIR.

Pour le pourcentage, la définition la plus utilisable vient de l'OCA : l'indisponibilité est la fraction du temps pendant laquelle un client légitime ne peut pas recharger, rapportée au temps normal de fonctionnement. L'exemple donné par l'OCA : une borne censée fonctionner en continu, hors service 3 jours sur 30, présente 10 % d'indisponibilité, soit 90 % de disponibilité.

Conséquence pratique : le statut publié au titre de l'AFIR et le calcul de disponibilité doivent venir de la même source, les statuts OCPP. Si les deux divergent, l'un des deux est faux.

Calculer les indicateurs depuis les messages OCPP

Les états : StatusNotification

Dans les deux versions d'OCPP, la borne remonte l'état de chaque connecteur par StatusNotification, et Unavailable et Faulted sont les états qui peuvent signaler une indisponibilité. La liste des statuts et des codes d'erreur est détaillée dans notre article sur les sessions de recharge échouées.

La méthode consiste à reconstituer, pour chaque point de charge, une suite d'intervalles d'état horodatés. Un passage en Faulted ouvre une panne, le retour à Available la ferme. La somme de ces intervalles donne le temps d'indisponibilité, leur durée moyenne le MTTR, leur nombre la base du MTBF. Le ticket d'intervention apporte le reste : heure de prise en charge pour le MTTA, début et fin de l'intervention pour le temps moyen d'intervention.

La connexion : Heartbeat, ping WebSocket, BootNotification

Une borne qui ne communique plus n'envoie pas de Faulted. L'OCA décrit trois signaux : le ping WebSocket, dont l'intervalle est configurable ; le Heartbeat, dont l'intervalle est fixé par le système central dans sa réponse au BootNotification et va habituellement de 15 minutes à 24 heures ; enfin le BootNotification lui-même, envoyé au redémarrage, qui trahit par exemple une coupure d'alimentation. L'intervalle choisi fixe la finesse de détection et pèse directement sur le MTTA.

Les sessions : StopTransaction et TransactionEvent

En OCPP 1.6, la fin de session arrive dans StopTransaction avec un motif : Local, Remote, EVDisconnected, PowerLoss, EmergencyStop, Reboot, HardReset, SoftReset, UnlockCommand, DeAuthorized ou Other. En OCPP 2.0.1, tout passe par TransactionEvent, de type Started, Updated puis Ended, avec un numéro de séquence (seqNo), un indicateur offline et, en fin de session, un stoppedReason plus détaillé : GroundFault, OvercurrentFault, PowerQuality, PowerLoss ou EmergencyStop, mais aussi SOCLimitReached, EnergyLimitReached ou StoppedByEV.

Pour le taux de sessions réussies, rangez chaque motif dans l'une de deux familles : fin normale (arrêt par l'usager, à distance, débranchement, limite atteinte) ou fin sur incident (défaut électrique, perte d'alimentation, redémarrage). Le taux est le nombre de sessions terminées normalement divisé par le nombre de sessions démarrées. Les motifs ambigus, comme Other, se suivent à part au lieu d'être rangés d'office dans une famille.

Les pièges de calcul

• Compter les arrêts planifiés comme des pannes. Une maintenance programmée, une commande ChangeAvailability ou une mise à jour de firmware passent les connecteurs en Unavailable. Marquez ces périodes dans la supervision et sortez-les du MTBF, sans les sortir de la disponibilité si le conducteur ne pouvait pas recharger.
• Confondre hors ligne et en panne. La spécification OCPP 1.6 prévoit qu'une borne fonctionne de façon autonome quand la communication tombe, avec autorisation locale si elle est configurée. À l'inverse, une panne survenue pendant la coupure n'est connue qu'au retour de la connexion. Gardez un état « inconnu » distinct.
• Horodater à la réception. Le champ timestamp du StatusNotification est facultatif en OCPP 1.6 : absent, c'est l'heure de réception qui fait foi. Les messages accumulés pendant une coupure arrivent en rafale. Utilisez l'horodatage de l'événement quand il existe et surveillez l'horloge des bornes.
• Croire que tous les changements d'état remontent. En OCPP 1.6, la borne peut omettre un StatusNotification si l'état a duré moins que la clé MinimumStatusDuration, et le fabricant peut avoir ajouté son propre délai. Les micro-coupures disparaissent alors des statistiques.
• Imputer à la borne ce qui vient du véhicule. Un défaut de dialogue avec le véhicule ne compte pas toujours comme indisponibilité : la méthode de tri est dans l'article sur les sessions échouées.
• Mélanger les granularités. Calculez par point de charge (EVSE) plutôt que par borne ou par site, puis agrégez (voir l'article sur les sessions échouées).
• Comparer des sessions qui ne commencent pas au même moment. En OCPP 2.0.1, les variables TxStartPoint et TxStopPoint fixent le début et la fin d'une transaction (branchement, autorisation, fermeture du circuit de puissance). Deux modèles réglés différemment ne produisent pas les mêmes comptes de sessions.
• Oublier les pannes invisibles. OCPP 1.6 n'a pas de code d'erreur pour un dommage physique : un câble arraché ou un écran cassé ne remonte pas toujours. Les signalements terrain et les visites préventives restent une source du calcul.
• Se fier à la seule moyenne. Une moyenne masque les cas longs. Publiez aussi la médiane et le cas le plus long de la période.

Ce que JCSM prend en charge

JCSM assure la supervision à distance OCPP et la maintenance préventive et curative de parcs multi-marques, en courant alternatif comme en courant continu. Nous définissons avec vous les indicateurs, les événements qui ouvrent et ferment chaque compteur et les règles de classement des statuts et des motifs d'arrêt, puis nous les suivons dans la durée. Le détail de l'offre est sur la page exploitation.

Questions fréquentes