OCPP 1.6 Déploiement. Garder les bornes en vie quand le réseau ne l'est pas

La spec OCPP vous dit quels messages envoyer. Elle ne vous dit pas ce qui se passe quand le modem 4G coupe à 3h du matin, quand une coupure de courant tue la borne en pleine session, ou quand 500 bornes essaient de se reconnecter simultanément après un redémarrage serveur. Ce post parle de ça.

La réalité de la connectivité des bornes

Les bornes vivent dehors. Elles se connectent en 4G/LTE, parfois en Wi-Fi, occasionnellement en Ethernet filaire. La connexion cellulaire coupe régulièrement. météo, congestion, maintenance des antennes, problèmes de SIM. Les coupures de courant arrivent plusieurs fois par semaine dans certaines régions. Les extrêmes de température causent des redémarrages.

Votre implémentation OCPP doit survivre à tout ça sans perdre de transactions ni laisser des bornes dans des états indéfinis.

Reconnexion : backoff exponentiel ou vous vous DDoS vous-même

Quand le WebSocket coupe, la borne doit se reconnecter. La mauvaise façon : réessayer immédiatement, en boucle serrée.

Rendering diagram...

Démarrer à 5 secondes, doubler à chaque essai, plafonner à 15 minutes. Ça empêche une flotte de 1 000 bornes de marteler votre serveur au même instant après un redémarrage backend. J'ai vu des backends tomber parce qu'ils avaient redémarré pendant les heures de pointe et 300 bornes s'étaient reconnectées simultanément sans backoff. La tempête de reconnexion était pire que la panne initiale.

Charge hors ligne : la borne doit continuer à fonctionner

Quand le WebSocket est coupé, la borne devrait :

1. Vérifier la Liste d'Autorisation Locale pour les badges RFID
2. Démarrer des sessions localement
3. Mettre en file chaque message : StartTransaction, MeterValues, StopTransaction
4. Rejouer la file dans l'ordre quand la connectivité revient

Rendering diagram...

Les timestamps dans les messages en file doivent être les originaux, pas l'heure du rejeu. Sinon les calculs de facturation sont faux et vous aurez des clients mécontents qui contestent des charges avec des timestamps qui ne correspondent pas à leur utilisation réelle.

Idempotence : les messages arriveront plus d'une fois

Les instabilités réseau causent des doublons. Votre backend doit les gérer :

• BootNotification reçu deux fois ? Répondez à nouveau.
• StartTransaction avec le même idTag + timestamp + connectorId ? Retournez le même transactionId. Ne créez pas deux transactions.
• StopTransaction reçu deux fois pour le même transactionId ? Arrêtez une fois, acquittez les deux. Ne facturez pas deux fois.

La règle : traitez en fonction du contenu, pas du fait que vous avez reçu un message.

Watchdogs

Côté borne : le firmware devrait avoir un watchdog matériel ou logiciel qui redémarre la pile OCPP si elle freeze, reboot la borne si elle ne répond plus. mais jamais pendant une session de charge active. C'est une question de sécurité.

Côté backend : Suivez la fraîcheur des heartbeats par borne.

Si une borne rate deux intervalles de heartbeat, quelque chose ne va pas. C'est peut-être juste un blip réseau. ou c'est une unité brickée qui nécessite une visite sur site.

Logging et observabilité

On ne peut pas déboguer ce qu'on ne peut pas voir. Loggez chaque message OCPP. dans les deux directions. avec timestamps, identifiant de borne et identifiant de message. Structurez-les pour pouvoir filtrer par borne, par transaction, par plage horaire.

Quand quelqu'un signale une erreur de facturation, vous voulez pouvoir remonter tout le cycle de vie de la transaction en une requête : Authorize → StartTransaction → chaque MeterValues → StopTransaction. Si vous ne pouvez pas faire ça en moins d'une minute, votre logging n'est pas encore assez bon.

Tests de charge

Avant de déployer à grande échelle, simulez :

• Tempêtes de reconnexion: déconnectez 500 bornes, laissez-les se reconnecter avec backoff
• BootNotifications en rafale: 500 boots simultanés après une coupure de courant
• MeterValues haute fréquence: chaque borne envoie toutes les 10 secondes

Si votre backend tombe pendant les tests, c'est mieux maintenant qu'en production avec des revenus réels en jeu.

La spec décrit un protocole. Le déploiement, c'est ce qui le fait vraiment fonctionner.