Tester une borne OCPP 1.6 sans laboratoire matériel

La plupart des bugs OCPP ne sont pas électriques. C’est un champ manquant, une mauvaise valeur d’énumération, une machine à états qui accepte un StartTransaction qu’elle aurait dû refuser. Rien de tout cela n’exige qu’un courant circule — autrement dit, l’essentiel du test OCPP peut se faire sur un portable.

Voici le montage que nous recommandons aux équipes qui attendent du matériel, ou qui en ont mais ne peuvent pas l’immobiliser à chaque commit.

Décidez quel côté vous testez

Cela paraît évident et c’est de loin la première source d’efforts gaspillés. Il y a deux choses indépendantes que l’on appelle « tester OCPP » :

Tester une borne. Vous avez un firmware censé parler OCPP et vous voulez savoir s’il le fait. Il vous faut quelque chose qui se comporte comme un CSMS et qui juge ce que la borne envoie.

Tester un CSMS. Vous avez un serveur et vous voulez savoir s’il encaisse ce que font les vraies bornes. Il vous faut quelque chose qui se comporte comme une borne et à qui l’on peut demander de mal se conduire.

Les deux demandent des outils opposés, et un outil conçu pour l’un est à peu près inutile pour l’autre. Tranchez d’abord.

Tester une borne

Pointez la borne vers un CSMS que vous contrôlez et regardez ce qu’elle dit. La borne ne sait pas — et ne se soucie pas — de savoir si le point de terminaison est une infrastructure de production ou un processus sur votre machine.

Réglez l’URL du système central de la borne sur votre point de terminaison. Presque toutes les bornes l’exposent dans une interface web ou un fichier de configuration, généralement sous une forme comme :

wss://10.0.1.50:9000/ocpp/CP001

Parcourez ensuite le flux de messages dans l’ordre, car les messages suivants dépendent des précédents :

1. BootNotification. Vérifiez que chargePointVendor et chargePointModel sont présents — les deux sont obligatoires, et les deux sont souvent laissés vides dans un firmware de jeunesse. Confirmez que la borne respecte l’interval que vous renvoyez au lieu d’en utiliser un codé en dur.
2. Heartbeat. Confirmez qu’il arrive à l’intervalle donné dans votre réponse au BootNotification, et que la borne s’ajuste si vous le changez via ChangeConfiguration.
3. StatusNotification. Faites passer le connecteur par Available, Preparing, Charging, Finishing. Guettez les transitions que la spécification interdit, et la borne qui annonce connectorId: 0 quand elle parle de la station entière.
4. StartTransaction / StopTransaction. Vérifiez le traitement de l’idTag contre chaque AuthorizationStatus que vous pouvez renvoyer — Accepted, Blocked, Expired, Invalid, ConcurrentTx. Refuser une transaction est le chemin le moins testé et le plus souvent cassé.
5. MeterValues. Confirmez que l’intervalle d’échantillonnage correspond à la configuration, et que les unités et les valeurs de measurand sont celles que vous attendez.

Le plus utile dans cet exercice est de renvoyer délibérément des échecs. Un firmware qui traite correctement Accepted et s’effondre sur Blocked est extrêmement courant, parce que le chemin heureux est le seul que quiconque ait parcouru.

Tester un CSMS

Ici il vous faut une borne simulée, et ce qui rend un simulateur utile n’est pas sa capacité à mener une session de recharge à son terme. C’est sa capacité à faire ce qu’une vraie borne fait quand quelque chose a mal tourné.

Les scénarios qui valent d’être automatisés :

• Démarrage à froid. Un BootNotification depuis une borne que le CSMS n’a jamais vue. Est-ce qu’il l’enrôle automatiquement, ou la refuse ?
• Reconnexion en pleine transaction. Coupez la socket pendant une transaction active, puis reconnectez-vous. La transaction doit survivre ; les index compteur ne doivent pas repartir de zéro.
• Dérive d’horloge. Envoyez des horodatages décalés de plusieurs heures. Un CSMS qui fait aveuglément confiance à l’horloge des bornes produira des enregistrements de facturation impossibles à rapprocher.
• StartTransaction en double. Même idTag, même connecteur, deux fois. ConcurrentTx existe pour une raison.
• Vidage de la file hors ligne. Mettez des messages en tampon pendant la déconnexion, puis livrez-les d’un coup à la reconnexion. C’est là que les CSMS naïfs perdent des données.
• Charges utiles malformées. Champs obligatoires absents, types erronés, valeurs d’énumération inconnues. Le CSMS doit renvoyer un CALLERROR, pas fermer la connexion ni faire tomber le worker.

L’échelle compte aussi, mais plus tard qu’on ne le croit. Cent bornes simulées trouveront vos bugs de concurrence ; dix mille trouveront surtout les limites de votre base de données, ce qui est une autre enquête.

Mettez-le en CI

La raison de faire tout cela en logiciel, c’est que le logiciel peut tourner à chaque commit. Un job de CI OCPP utile ressemble à ceci :

1. démarrer le CSMS à tester
2. démarrer N bornes simulées contre lui
3. dérouler un scénario scripté — connexion, démarrage, autorisation, recharge, arrêt, déconnexion
4. affirmer sur l’état obtenu : transactions closes, index compteur monotones, aucune session orpheline
5. démonter et rendre compte

Cela attrape les régressions que le test matériel attrape trop tard. Un changement qui casse les codes de raison de StopTransaction coûte peu à trouver en CI et cher à trouver en essai terrain.

Ce que cela ne couvre pas

Être honnête sur les limites compte, parce qu’une suite de tests verte qui cache toute une classe de défaillances est pire que pas de suite du tout.

Le comportement électrique et de sécurité. Temporisation des contacteurs, détection de défaut à la terre, déclassement thermique, arrêt d’urgence. Rien de tout cela n’est visible via OCPP, et rien ne peut être simulé.

Les conditions réseau réelles. Les bornes vivent sur des liaisons cellulaires derrière le NAT de l’opérateur. Pertes de paquets, latences de plusieurs secondes, coupures silencieuses — un simulateur sur localhost ne reproduira pas cela, et c’est responsable d’une large part des incidents en production.

Les particularités des fabricants. Chaque constructeur interprète différemment un coin de la spécification. On les découvre en branchant du matériel réel de ce fabricant, et il n’y a pas de substitut.

La certification formelle. Passer vos propres tests n’est pas une certification OCPP. Cela passe toujours par le processus de l’OCA et son outil de test.

La forme d’un programme sensé est donc : le test logiciel attrape la majorité des défauts, en continu et à bas coût ; le test matériel confirme ce que seul le matériel peut confirmer ; la certification vient quand les deux premiers sont propres.

Outillage

Il existe du bon travail open source dans ce domaine — docile-charge-point est scriptable et existe depuis des années, et la bibliothèque Python ocpp vous donne des briques pour l’un ou l’autre côté.

Nous construisons TestPilot pour le premier métier — un CSMS qui juge une borne et exporte un rapport de conformité — et SimPilot pour le second, qui simule des bornes contre votre serveur, modes de défaillance ci-dessus inclus. Si vous voulez la couche protocolaire à l’intérieur de votre propre service Go plutôt qu’un outil à côté, OcppPilot est la bibliothèque sur laquelle les deux autres sont bâtis.