OCPP

Référence du pilote OCPP : le système central intégré, les certificats des points de charge, les tags de connecteur et la règle de nommage Meter et Status.

Le pilote OCPP fait de Ganter Lab le système central des points de charge de véhicules électriques qui parlent le protocole Open Charge Point. Comme pour LoRaWAN, le sens est inversé : la station ne se connecte pas au chargeur, c'est le point de charge qui se connecte à Ganter Lab par un WebSocket, s'enregistre, et y pousse sa télémétrie.

Le système central intégré démarre quand le premier équipement OCPP activé est chargé dans le connecteur en fonctionnement, et s'arrête quand le dernier est retiré ou désactivé : sans aucun point de charge configuré, rien n'écoute sur le port. En ajouter un le fait revenir, sans redémarrer l'application. Chaque équipement que vous configurez représente un point de charge, identifié par l'identifiant sous lequel il se connecte.

Système central et ports

L'écouteur est toujours en TLS; un écouteur en HTTP simple est refusé partout sauf sur la boucle locale, qui n'existe que pour les essais en processus. Un point de charge s'enregistre par sa BootNotification (à laquelle il est répondu avec un intervalle de battement de 60 secondes), et chaque badge présenté pour autorisation est accepté : Ganter Lab observe la charge, il ne gère ni les tarifs ni les accès.

Certificats

Le côté serveur de la poignée de main TLS présente le certificat OPC UA propre à l'application. Chaque point de charge doit présenter un certificat client :

1. Il doit construire une chaîne valide sur cette machine Windows, sans erreur de politique TLS; un contrôle en échec refuse la connexion et le journal enregistre quel contrôle a échoué.
2. Son nom commun de sujet, ou un autre nom de sujet DNS, doit nommer l'identifiant du point de charge sous lequel il se connecte. Un certificat qui nomme un autre point de charge que celui du chemin de connexion est refusé.

Une poignée de main sans certificat client est abandonnée avant qu'aucune donnée ne circule.

Champs de connexion

Il n'y a ni champ d'hôte, ni de port, ni d'identifiants : c'est le chargeur qui détient les détails de connexion, et cette station n'a besoin de savoir que quel point de charge l'équipement désigne. Il n'y a pas non plus de champ d'intervalle de scrutation. OCPP fonctionne par poussée (le point de charge envoie ses messages MeterValues et StatusNotification à son propre rythme) et les tags se rafraîchissent à partir des dernières données reçues, sur un cycle fixe d'une seconde.

Un point de charge qui ne s'est pas encore connecté, ou un connecteur qui n'a pas encore rapporté, n'a donc aucune lecture, et non une lecture en échec. Ses tags restent vides, l'équipement signale que rien n'a été observé plutôt que de passer hors ligne, et aucun échec n'est journalisé : c'est l'état normal d'un point de charge qui vient d'être configuré et qui n'est pas encore arrivé.

Tags

Un tag OCPP lit un connecteur du point de charge (un connecteur au sens d'OCPP : une position de prise, numérotée à partir de 1). Deux sortes de tags existent, distinguées par le suffixe du nom du tag, qui est validé :

Un nom sans l'un ou l'autre suffixe est refusé par la validation : nommez les tags comme Connector1Meter et Connector1Status.

Les tags OCPP sont en lecture seule : le champ d'accès n'offre aucun choix inscriptible, et une écriture est refusée plutôt que feinte. Commander un point de charge est une commande à part, décrite ci-dessous, non une valeur écrite dans un tag.

Commandes

Un point de charge se commande autant qu'il se lit. Chaque équipement OCPP porte les commandes ci-dessous comme méthodes sur l'équipement dans l'espace d'adressage OPC UA propre à cette station, si bien que tout ce qui sait appeler une méthode peut en lancer une : un client OPC UA, ou une action Logic qui l'appelle.

Chaque commande prend l'identifiant du point de charge comme premier argument, et rend la réponse propre au point de charge comme résultat.

AttributeType vaut Actual, Target, MinSet ou MaxSet.

Attendre la réponse. Une commande n'est pas terminée quand la station l'a envoyée. La station tient l'appel ouvert jusqu'à ce que le point de charge réponde à l'ordre même qu'elle a envoyé, apparié par l'identifiant de corrélation qui voyage avec lui, et c'est seulement alors qu'elle rapporte un succès et rend la réponse. Trois choses y mettent fin autrement, chacune rapportée comme un échec avec sa raison :

• Le point de charge n'est pas connecté, ou sa connexion n'est pas ouverte. Rien n'est envoyé.
• Le point de charge répond par une erreur OCPP, par exemple pour une commande qu'il n'implémente pas. Le code d'erreur est la raison.
• 30 secondes passent sans aucune réponse. Une commande que personne n'a répondue est un échec, jamais un succès.

Une commande lancée pour un point de charge qu'un équipement ne porte pas, ou qui n'est pas connecté, est refusée tout de suite plutôt que mise en file.

Découverte

Découvrir sur le pilote OCPP liste les points de charge actuellement connectés au système central, et lire les voies d'un candidat propose un tag Meter et un tag Status par connecteur que le point de charge a rapporté jusqu'ici.

Le premier point de charge se configure toujours à la main. Rien ne peut se connecter avant que le système central n'écoute, et il n'écoute qu'une fois qu'un équipement OCPP existe ici : un balayage sur une installation sans point de charge configuré ne trouve donc rien et le dit. Ajoutez ce premier équipement avec l'identifiant sous lequel le chargeur se connectera; après cela, un chargeur qui s'est connecté peut être découvert. Le déroulement général de la découverte est décrit sur la page Connector.

L'identifiant est comparé sans tenir compte de la casse, dans le certificat, dans le chemin de connexion et face à l'équipement : un chargeur qui se connecte comme cp-a avec un certificat qui nomme CP-A est le même point de charge qu'un équipement dont l'identifiant indique CP-A.