Qu’est-ce qu’OCPP ?
OCPP — Open Charge Point Protocol — est la norme du secteur pour la communication entre les bornes de recharge (Charge Points) et les systèmes de gestion côté serveur (Central System Management Software, ou CSMS). La version 1.6 est aujourd’hui la plus déployée sur le terrain.
Le protocole s’appuie sur WebSocket. La borne est toujours le client WebSocket ; le CSMS est le serveur. Les messages sont en JSON (dans la variante -J, celle que tout le monde utilise réellement).
Le format des messages
Tout message OCPP est un tableau JSON de structure fixe :
[MessageTypeId, UniqueId, Action, Payload]- MessageTypeId : 2 = Call (requête), 3 = CallResult (réponse), 4 = CallError
- UniqueId : une chaîne que vous générez pour apparier requêtes et réponses
- Action : le nom de l’opération (par exemple « BootNotification »)
- Payload : le corps du message, sous forme d’objet JSON
Un échange BootNotification typique ressemble à ceci :
// Borne → CSMS
[2, "19223201", "BootNotification", {
"chargePointModel": "SingleSocketCharger",
"chargePointVendor": "VendorX"
}]// CSMS → Borne
[3, "19223201", {
"currentTime": "2026-03-05T10:00:00Z",
"interval": 300,
"status": "Accepted"
}]Les flux de messages essentiels
Séquence de démarrage
Au démarrage, une borne doit envoyer BootNotification et attendre Accepted avant toute autre chose. Si le CSMS répond Pending ou Rejected, la borne doit se mettre en retrait et réessayer à l’intervalle indiqué dans la réponse.
Une fois BootNotification accepté, la borne envoie un StatusNotification par connecteur, puis commence à émettre des Heartbeat à l’intervalle que le CSMS a fixé.
Autorisation
Avant de démarrer une transaction, la borne doit généralement autoriser l’utilisateur. Elle envoie Authorize avec l’idTag (le badge RFID), et le CSMS répond par un AuthorizationStatus. Les statuts qui comptent sont :
- Accepted : autoriser la transaction
- Blocked : badge bloqué, ne pas démarrer
- Expired : badge expiré
- Invalid : badge inconnu
- ConcurrentTx : le badge a déjà une transaction en cours ailleurs
Déroulé d’une transaction
StartTransaction → [le CSMS attribue un transactionId]
→ StatusNotification (Charging)
→ MeterValues (périodique, optionnel)
→ StopTransaction → [le CSMS clôt la transaction]
→ StatusNotification (Available)Le transactionId issu de StartTransaction doit être repris dans StopTransaction et dans tous les MeterValues de la session.
Commandes à distance
Le CSMS peut envoyer des commandes à la borne. Les principales à implémenter :
- RemoteStartTransaction / RemoteStopTransaction : démarrer ou arrêter une session
- Reset : redémarrage Soft (propre) ou Hard (immédiat)
- ChangeAvailability : mettre un connecteur en ou hors service
- GetConfiguration / ChangeConfiguration : lire et écrire les clés de configuration
- UnlockConnector : libérer physiquement le câble
Erreurs d’implémentation courantes
1. Ne pas tenir compte du frein posé par un BootNotification Pending
Certaines bornes ignorent une réponse Pending et se mettent à envoyer des Heartbeat immédiatement. La spécification est claire : attendez Accepted.
2. Utiliser des transactionId périmés
Utilisez toujours le transactionId attribué par le CSMS dans StartTransaction.CallResult. Ne réutilisez jamais l’identifiant d’une session précédente.
3. Ne pas envoyer de StatusNotification après StopTransaction
À la fin d’une transaction, le statut du connecteur doit revenir à Available (ou Preparing, ou Faulted, selon l’état). L’oublier laisse le CSMS avec un état de connecteur périmé.
4. Ignorer l’intervalle de heartbeat
Le CSMS vous indique dans la réponse au BootNotification à quelle fréquence envoyer Heartbeat. Utilisez cette valeur, pas une valeur codée en dur.
Tester votre implémentation
C’est là qu’intervient TestPilot. Il simule un CSMS et fait passer votre borne par tous ces flux, en vérifiant à chaque étape la structure et l’enchaînement des messages. Dès la première exécution, vous attraperez l’essentiel des problèmes de conformité.