OCPP

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

Le pilote OCPP fait de Ganter Lab le système central des bornes de recharge 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 la borne 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 aucune borne configurée, rien n'écoute sur le port. En ajouter une la fait revenir, sans redémarrer l'application. Chaque équipement que vous configurez représente une borne, identifiée par l'identifiant sous lequel elle se connecte.

Préparer la borne

C'est la borne qui appelle cette station et, en sortie d'usine, elle ne sait pas où la station se trouve. La page de chaque équipement OCPP porte la carte Préparer la borne, avec ce qu'il faut entrer dans les réglages OCPP de la borne, écrit pour cette station :

La carte est ouverte tant que la borne ne s'est pas connectée depuis l'ouverture de la station, et se replie une fois qu'elle s'est connectée : elle reste sur la page pour la prochaine fois que la borne sera configurée. Une borne dont aucune racine installée dans Windows ne garantit le certificat est refusée à sa première connexion et attend dans Accès des équipements.

Le fichier est écrit au premier démarrage du système central, dès qu'une borne est enregistrée, et jusque-là la carte le dit. C'est le même fichier pour toutes les bornes de cette station, et il ne change pas quand le nom ou les adresses de la station changent (voir Le certificat racine de la station).

Toute borne qui a reçu un fichier d'une version antérieure a besoin de celui-ci, installé une fois. Au premier démarrage de cette version, une station dont les bornes peuvent détenir un fichier antérieur affiche sur la carte un avis, Le fichier de cette station a changé, dans cette exécution seulement. L'avis est un rappel, pas la consigne : installez le nouveau fichier une fois sur chaque borne d'une station qui avait déjà des bornes, que la carte affiche l'avis ou non. Une borne qui vérifie le nom du serveur accepte ensuite la station.

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. Une borne 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 un certificat signé par la racine propre à cette station (voir Le certificat racine de la station). Chaque borne doit présenter un certificat client :

1. Il doit être digne de confiance de l'une de deux façons : il construit une chaîne valide sur cette machine Windows, jusqu'à une racine qui y est installée, sans erreur de politique TLS; ou vous avez approuvé ce certificat précis sous Accès des équipements sur la page de ce pilote (plus bas). Dans les deux cas, il doit être dans ses dates de validité. 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 de la borne sous lequel elle se connecte. Un certificat qui nomme une autre borne que celle du chemin de connexion est refusé, même approuvé.

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

Le certificat racine de la station

Une racine enregistrée qui ne peut plus être ouverte, par exemple parce qu'elle a été écrite par un autre compte Windows, est remplacée par une nouvelle. Chaque borne a alors besoin du nouveau fichier, une fois, et la carte le dit.

Accès des équipements

Une borne dont aucune racine installée dans Windows ne garantit le certificat, parce qu'il est auto-signé ou émis par l'autorité du fabricant lui-même, n'a pas besoin que cette racine soit installée sur cet ordinateur. Sa première connexion est refusée, et son certificat attend sous Accès des équipements, à la fin de la page du pilote OCPP, la même carte que celle de la page du pilote OPC UA, jusqu'à ce que vous décidiez :

Chaque certificat est approuvé pour lui-même, jamais l'autorité qui l'a signé : une deuxième borne du même fabricant attend donc sa propre approbation. Comparez l'empreinte avec celle qu'indique la borne avant de l'approuver. L'approbation ne change pas la borne que le certificat désigne : il reste admis uniquement sous l'identifiant de la borne qu'il nomme, et uniquement dans ses dates de validité. Un certificat auquel Windows fait déjà confiance est admis comme avant et n'apparaît jamais ici; rien n'est approuvé automatiquement.

Les décisions sont gardées dans le dossier de données de la station, sous ua\pki\ocpp, et survivent à un redémarrage. Seul un rôle qui peut configurer le Connector reçoit les commandes, et elles n'agissent que dans la fenêtre de la station elle-même : un navigateur sur un autre appareil lit la carte sans la modifier, et aucun outil d'agent n'approuve un certificat. La liste garde jusqu'à 100 certificats en attente d'approbation; une fois pleine, un nouveau certificat reste refusé mais n'est pas listé, et la carte le dit.

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 quelle borne l'équipement désigne. Il n'y a pas non plus de champ d'intervalle de scrutation. OCPP fonctionne par poussée (la borne 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.

Une borne qui ne s'est pas encore connectée, ou un connecteur qui n'a pas encore rapporté, n'a donc aucune lecture, et non une lecture en échec. Ses tags restent vides et aucun échec n'est journalisé : une valeur que la borne n'a pas encore envoyée, c'est le protocole qui fonctionne.

L'état de santé de la borne

Comme une borne envoie ses valeurs quand elle en a, le silence de ses tags ne peut pas distinguer une borne qui n'a pas encore rapporté d'une borne qui n'est plus là. Son état de santé, le point sur sa ligne dans l'arborescence et la colonne État de santé sur la page du pilote, suit plutôt sa connexion au système central de cette station :

Tant que la borne est connectée, un connecteur qui n'a pas encore rapporté ne compte pas contre elle. Pendant au plus dix secondes après l'enregistrement d'une modification de la borne, ou le démarrage du Connector, elle se lit Pas encore connu : remettre l'équipement en place peut redémarrer le système central, et la borne met un moment à se reconnecter.

Tags

Un tag OCPP lit un connecteur de la borne (un connecteur au sens d'OCPP : une position de prise, numérotée à partir de 1). En OCPP 2.0, 2.0.1 et 2.1, le numéro est celui de l'EVSE, puisque les connecteurs y sont renumérotés à partir de 1 dans chaque EVSE. Trois sortes de tags existent, distinguées par le suffixe du nom du tag, qui est validé :

Un nom sans l'un de ces suffixes est refusé par la validation : nommez les tags comme Connector1Meter, Connector1Status et Connector1Transaction.

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 une borne est une commande à part, décrite ci-dessous, non une valeur écrite dans un tag.

Commandes

Une borne 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 qu'un client OPC UA connecté à cette station en lance une en appelant la méthode.

Chaque commande prend l'identifiant de la borne comme premier argument, et rend la réponse propre à la borne comme résultat.

AttributeType vaut Actual, Target, MinSet ou MaxSet.

D'où vient le TransactionId. RemoteStopTransaction et GetTransactionStatus agissent sur une transaction, désignée par son numéro. Lisez-le dans le tag Transaction du connecteur sur lequel la session charge (l'EVSE en OCPP 2.x), par exemple Connector1Transaction, et transmettez-le tel qu'il se lit. Un texte vide à cet endroit signifie qu'aucune transaction n'est en cours sur ce connecteur.

Un seul catalogue, peu importe la version. Les commandes gardent les noms ci-dessus, peu importe la version que parle la borne, et la station envoie chacune sous la forme que cette version définit. En OCPP 2.0, 2.0.1 et 2.1, les connecteurs sont regroupés sous des EVSE, et le numéro fourni comme ConnectorId désigne l'EVSE.

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 la borne 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 :

• La borne n'est pas connectée, ou sa connexion n'est pas ouverte. Rien n'est envoyé.
• La borne répond par une erreur OCPP, par exemple pour une commande qu'elle 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 une borne qu'un équipement ne porte pas, ou qui n'est pas connectée, est refusée tout de suite plutôt que mise en file.

Découverte

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

La première borne 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 borne configurée 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 la même borne qu'un équipement dont l'identifiant indique CP-A.

Une borne que vous avez déjà relit ses connecteurs depuis sa propre page : Découvrir les tags, dans l'en-tête de sa carte Tags, propose les tags Meter, Status et Transaction de chaque connecteur qu'elle a rapporté pendant qu'elle était connectée et pour lequel l'équipement n'a pas encore de tag (voir Découvrir les tags d'un équipement).