STOP CHARGING

Comment arrêter une session de recharge avec StopTransaction

Intro

Pour arrêter un OCPP lors d'une session de recharge, le chargeur du véhicule électrique (VE) et le système de gestion de la charge doivent suivre un processus strict. Si cela n'est pas fait correctement, cela peut générer des erreurs et bloquer les chargeurs de véhicules électriques pour le conducteur suivant.

Il existe de nombreuses façons d'arrêter la session de recharge des véhicules électriques (et nous les examinerons toutes). Cependant, les déclencheurs les plus courants sont les suivants : l'utilisateur appuie sur un bouton d'arrêt de l'interface utilisateur du chargeur pour véhicule électrique, le véhicule électrique atteint sa pleine charge ou le chargeur décide d'arrêter la session de recharge (par exemple, limite de temps atteinte ou erreur matérielle).

Quelle que soit la méthode utilisée pour arrêter la session, le chargeur EV (client OCPP) enverra une nouvelle notification d'état et une demande StopTransaction au système de gestion de la recharge (backend OCPP).

Ces messages OCPP mettent fin à la session de recharge et font partie des messages les plus courants dans le monde de la recharge des véhicules électriques. Si vous ne l'avez pas encore fait, nous vous recommandons de comprendre comment démarrer une session de recharge de véhicule électrique avant d'apprendre comment en arrêter une. Pour ce faire, veuillez lire le Guide OCPP StartTransaction premier.

Pour arrêter la session de facturation OCPP, également appelée transaction, initiée par le client OCPP, nous avons besoin des messages OCPP suivants :

  • Demande de notification d'état
  • Requête StopTransaction

Comment utiliser une mise à jour des notifications de statut pour arrêter une session de recharge OCPP

Avant d'arrêter une session de recharge, le chargeur de véhicule électrique est en mode « recharge ». Cela signifie qu'une session de recharge a déjà été initiée et que la dernière notification d'état envoyée par le chargeur du véhicule électrique était « en cours de chargement ».

Afin d'arrêter la session de recharge, le chargeur EV envoie une nouvelle demande StatusNotification (StatusNotification.req) au backend OCPP. La notification d'état fera passer l'état actif de « recharge » à l'un des statuts de borne de recharge suivants :

  • « Disponible »
  • « Dev suspendu »
  • « Finition »
  • « Indisponible »
  • « Faute »

La diversité des types de statut reflète la diversité des raisons pour lesquelles une session de recharge prend fin. Nous expliquons ci-dessous les conditions qui déclenchent l'état de chaque borne de recharge :

« Chargement » → « Disponible »
La session de recharge se termine alors qu'aucune action de l'utilisateur n'est requise (par exemple, le câble fixe a été retiré du côté du véhicule électrique).

« Chargement » → « SuspendeDev »
La recharge s'arrête à la demande du véhicule électrique (le véhicule électrique ne consomme pas d'énergie supplémentaire).

« Chargement » → « Système d'exploitation suspendu »
La recharge s'arrête à la demande de l'EVSE (Electric Vehicle Supply Equipment) (par exemple, restriction de recharge intelligente, la transaction n'a pas été correctement autorisée dans un StartTransaction.conf).

« Chargement » → « Finition »
L'utilisateur arrête la transaction via l'interface utilisateur du chargeur ou un message RemoteStopTransaction + une autre action de l'utilisateur est requise (par exemple, retirer le câble et quitter l'aire de stationnement).

« Chargement » → « Non disponible »
La session de recharge est terminée + aucune action de l'utilisateur n'est requise + le connecteur devrait devenir indisponible.

« Chargement » → « Défaillant »
Un défaut est détecté qui empêche d'autres opérations de charge (erreur du chargeur).

Cela peut sembler complexe ou inutile, mais cela donne de nombreuses informations importantes sur l'erreur du chargeur pendant l'opération de charge et aidera à exploiter efficacement les points de recharge.

En résumé, lorsque le chargeur de véhicule électrique souhaite lancer l'arrêt de la session de recharge, il envoie un nouveau message StatusNotification.Req au serveur OCPP, passant de « chargement » à l'une des transactions de statut ci-dessus. Sans cette mise à jour de statut, le chargeur n'arrêtera pas de charger.

Si le backend OCPP est prêt, il répondra par un message StatusNotification.conf pour confirmer que le message a été reçu et compris. La confirmation ne contient aucune information.

Ci-dessous, vous pouvez voir le flux de la demande de notification de statut dans OCPP :

Status Notification Diagram from the OCPP 1.6J documentation

Comme indiqué plus haut, le Notification d'état. Req Le message est largement utilisé dans de nombreux scénarios au-delà de la fin de la session. Il contient les informations suivantes :

  • ID du connecteur : Identifiant du connecteur de charge, qui est généralement 1 ou 2. Si la borne de recharge comporte plusieurs prises, ce nombre sera plus élevé.
  • Code d'erreur: indique les erreurs potentielles signalées par le chargeur. Pour démarrer la session, celle-ci doit idéalement contenir « NoError ». Cependant, les erreurs possibles peuvent être « EvCommunicationError », « UnderVoltage », etc. Dans de nombreux cas, le statut indiquera « OtherError » et un code d'erreur du fournisseur dans le champ supplémentaire info ou VendorErrorCode champ. Pour les opérations de grande envergure, ces codes d'erreur deviennent très importants et fournissent des informations sur d'éventuelles erreurs matérielles.
  • statut: Comme mentionné ci-dessus, cela devrait passer de « Chargement » à « Disponible », « Finition », etc.

statusNotification.req message fields OCPP 1.6J
statusNotification.req message fields OCPP 1.6J

Remarque: Si le chargeur possède plusieurs prises, l'ID du connecteur sera numéroté 1, 2, 3, etc. C'est important car certains chargeurs permettent une charge simultanée. Le connecteur 1 peut alors être à l'état « Disponible » alors que le connecteur 2 est toujours à l'état « En cours de chargement ». Si une seule prise peut être chargée à la fois, les autres connecteurs doivent envoyer une demande StatusNotification contenant le statut « Indisponible ».

Vous pouvez voir ici un exemple de Notification d'état. Req

{
« ID du connecteur » : 2,
« ErrorCode » : « Aucune erreur »,
« status » : « SuspendeDev »,
« horodatage » : « 09-12T 10:01:00.515 Z »
}

Comment arrêter la demande de transaction et le rapport énergétique dans OCPP

Une fois le statut « Charging » passé de « Charging » à l'un des six statuts possibles, le chargeur EV enverra la demande StopTransaction (StartTransaction.Req).

Le délai entre le changement de statut et la demande d'arrêt de transaction peut varier en fonction du fabricant de l'EVSE. Chez Ampcontrol, nous avons observé des temps compris entre 1 seconde et 10 secondes. Il s'agit des informations essentielles indiquant que la recharge a été arrêtée, envoyées du client OCPP au serveur OCPP.

À la réception d'un fichier StopTransaction.req, le serveur OCPP répond par un fichier StopTransaction.conf. Par conséquent, le serveur vérifiera les informations contenues dans la demande d'arrêt de transaction, telles que le TransactionID, l'horodatage ou l'IDtag.

Stop Transaction Diagram from the OCPP 1.6J documentation

Outre un horodatage d'arrêt, le TransactionID et l'IDTag, le message OCPP StopTransaction contient également deux champs utiles : reason et MeterStop.

Le champ « raison » identifie le déclencheur de la fin de la session de recharge. Cela aide l'opérateur de la borne de recharge à résoudre les problèmes liés à l'opération de recharge et peut informer le conducteur de la raison pour laquelle sa session de recharge a été interrompue. Les raisons possibles sont les suivantes :

  • Local: Arrêté localement à la demande de l'utilisateur à la borne de recharge. Il s'agit d'une résiliation régulière d'une transaction. Exemples : présentation d'une étiquette RFID ou appui sur un bouton pour arrêter.
  • Perte de puissance: perte totale de puissance.
  • Redémarrer: une réinitialisation/un redémarrage initiés localement s'est produit.
  • télécommande: Arrêté à distance à la demande de l'utilisateur. Il s'agit d'une résiliation régulière d'une transaction, par exemple à l'aide d'une application pour smartphone ou en cas de dépassement d'un crédit prépayé (non local).
  • SoftReset : une commande de réinitialisation logicielle a été reçue.
  • EV déconnecté: Le bouton d'arrêt d'urgence a été utilisé ou le véhicule a été déconnecté.
  • Désautorisé: La transaction a été arrêtée en raison de l'état d'autorisation dans un fichier StartTransaction.conf
  • Autres: Pour toute autre raison
  • Commande de déverrouillage: le backend OCPP a envoyé une commande Unlock Connector (permet de déverrouiller physiquement une prise de recharge).

Le champ « MeterStop » indique la consommation d'énergie à la fin de la session de recharge. Cela permet de déclarer correctement le total des kilowatts chargés et les coûts énergétiques totaux pour cette transaction de recharge.

Remarque: Le backend OCPP (CMS) applique généralement un contrôle d'intégrité pour vérifier les données contenues dans le fichier StopTransaction.req. Cependant, le backend OCPP doit toujours répondre par un fichier StopTransaction.conf. Si vous ne répondez pas avec un fichier StopTransaction.conf, le Point de charge essaiera à nouveau d'envoyer le même message, comme indiqué dans Réponses d'erreur aux messages liés aux transactions.

Pour résumer, la demande et le message de confirmation contiennent tous deux des informations essentielles dont nous souhaitons discuter :

  • Tag d'identification : Affiche l'identifiant qui a demandé l'arrêt de la recharge. Elle est facultative car une borne de recharge peut mettre fin à la recharge sans la présence d'un identifiant, par exemple en cas de réinitialisation.
  • Arrêt du compteur : Contient la valeur du compteur en Wh pour le connecteur à la fin de la transaction. 
  • horodatage : Contient la date et l'heure auxquelles la transaction a été arrêtée.
  • ID de transaction : Contient l'ID de transaction tel qu'il a été reçu par Démarrez Transaction.conf.
  • raison : Indique la raison pour laquelle la transaction a été arrêtée.
  • Données sur les transactions : Il contient des informations sur l'utilisation des transactions pertinentes à des fins de facturation. De plus, l'élément TransactionData est utilisé comme conteneur pour un nombre quelconque de MeterValues, en utilisant la même structure de données que les éléments MeterValue du Valeurs des compteurs OCPP. Req
  • Informations sur l'IDTAG: contient des informations sur l'état de l'autorisation, son expiration et l'identifiant du parent.

Vous pouvez voir ici un exemple pour un fichier StopTransaction.req et le fichier StopTransaction.conf :

Arrêter la transaction.req

{
« reason » : « Local »,
« Numéro de transaction » : 568161113,
« MeterStop » : 4329600,
« horodatage » : « 06-09-08T 10:31:26.127 Z »
}

Arrêtez Transaction.conf

{
« Informations sur l'IDTag » :
{
« status » : « Accepté »
}
}

Résumé

Les messages StopTransaction et StatusNotification sont des messages OCPP importants qui sont fréquemment utilisés sur les réseaux de recharge pour véhicules électriques ou les bornes de recharge privées.

La procédure typique pour mettre fin à une session de recharge est la suivante :

  1. Changez l'état du chargeur de « Chargement » à « Disponible », « SuspendeDev », etc.
  2. Arrêtez le processus de charge via l'interaction de l'utilisateur, le véhicule, le chargeur ou la télécommande.
  3. Le chargeur EV envoie le message StopTransaction.req, qui contient les valeurs des compteurs pour des rapports appropriés.
Schéma

Intro

Comment utiliser une mise à jour des notifications de statut pour arrêter une session de recharge OCPP

Comment arrêter la demande de transaction et le rapport énergétique dans OCPP

Résumé