OCPP 1.6 vs 2.0.1 : ce qui change pour vos bornes de recharge

OCPP est le protocole qui permet à une borne de recharge de communiquer avec son système de gestion central. La version 1.6, publiée en 2015, est encore largement déployée. La version 2.0.1, publiée en 2020, apporte des changements structurels en matière de sécurité, de modélisation des équipements et de gestion de la charge intelligente. Cet article détaille les différences techniques entre les deux versions et ce qu'elles impliquent pour les opérateurs.

OCPP : le protocole standard des bornes de recharge

OCPP (Open Charge Point Protocol) est un protocole de communication ouvert, développé et maintenu par l'Open Charge Alliance (OCA), un consortium international regroupant des fabricants de bornes, des opérateurs de réseaux et des éditeurs de logiciels de supervision.

Le principe est simple : standardiser les échanges entre la borne (Charge Point) et le serveur de gestion (CSMS - Charging Station Management System). Sans protocole commun, chaque fabricant imposerait son propre format de communication, rendant impossible la gestion d'un parc multi-marques depuis un seul système central.

OCPP utilise des messages JSON sur WebSocket (OCPP-J) ou SOAP sur HTTP (OCPP-S, en déclin). La connexion est initiée par la borne vers le CSMS, puis maintenue en bidirectionnel : la borne envoie des notifications (statut, erreurs, mesures), le serveur envoie des commandes (redémarrage, changement de configuration, mise à jour firmware).

OCPP 1.6 : fonctionnalités et limites

OCPP 1.6 reste la version la plus déployée dans le monde. Elle couvre les fonctions essentielles de la supervision : authentification par badge RFID, démarrage et arrêt de session, remontée de statut, redémarrage à distance, mise à jour firmware, et un premier niveau de smart charging (profils de charge).

Ce que fait bien OCPP 1.6

• Gestion de sessions : StartTransaction, StopTransaction, MeterValues pour le suivi de la consommation en temps réel
• Supervision de base : StatusNotification, Heartbeat, GetDiagnostics, Reset
• Smart charging (limité) : SetChargingProfile permet de définir des profils de puissance avec des périodes et des limites, mais uniquement au niveau du connecteur ou de la borne
• Configuration à distance : ChangeConfiguration avec une liste de clés standardisées (HeartbeatInterval, MeterValueSampleInterval, etc.)
• Réservation : ReserveNow et CancelReservation pour bloquer un connecteur

Les limites d'OCPP 1.6

• Pas de device model : la borne est une boîte noire. Le CSMS ne connaît pas la structure interne (nombre de compteurs, type de connecteurs, version du modem). Les diagnostics reposent sur des informations statiques déclarées manuellement
• Sécurité limitée : pas de profils de sécurité formalisés. L'authentification entre borne et CSMS se limite à un identifiant (ChargeBoxIdentity) sans mécanisme de certificat intégré au protocole
• Pas de support ISO 15118 : le Plug & Charge, qui permet au véhicule de s'authentifier automatiquement via un certificat TLS, n'est pas prévu par le protocole. Certains fabricants l'ajoutent via DataTransfer (messages propriétaires), sans garantie d'interopérabilité
• Gestion de transaction fragile : une transaction est identifiée par un TransactionId entier, attribué par le CSMS. En cas de perte de connexion pendant une session, la réconciliation des données est complexe
• Messages d'affichage absents : impossible d'envoyer un message texte à afficher sur l'écran de la borne (utile pour informer les utilisateurs d'une maintenance programmée, par exemple)

OCPP 2.0.1 : les améliorations majeures

OCPP 2.0.1 n'est pas une simple mise à jour de 1.6. C'est une refonte du protocole avec une architecture de messages entièrement redessinée. Les noms d'opérations changent, la structure de données évolue, et de nouveaux concepts apparaissent.

Device model

L'apport le plus structurant. En 2.0.1, chaque composant de la borne est modélisé : EVSE (point de charge), connecteur, compteur d'énergie, contrôleur, modem. Chaque composant possède ses propres variables (état, version, configuration). Le CSMS peut interroger n'importe quel composant individuellement via GetVariables et SetVariables.

Concrètement, au lieu de demander une clé générique comme MeterValueSampleInterval, le CSMS peut cibler le compteur d'un EVSE spécifique et lire sa précision, son dernier calibrage ou son firmware. Cela permet un diagnostic beaucoup plus fin et une gestion d'inventaire automatisée.

Profils de sécurité

OCPP 2.0.1 définit trois profils de sécurité hiérarchiques :

• Profil 1 : authentification par mot de passe HTTP Basic (niveau minimal, comparable à 1.6)
• Profil 2 : TLS avec certificat serveur. La borne vérifie l'identité du CSMS via un certificat X.509. Le canal est chiffré
• Profil 3 : TLS mutuel avec certificat client. La borne et le CSMS s'authentifient mutuellement par certificats. C'est le niveau requis pour le Plug & Charge

Le protocole inclut aussi la gestion du cycle de vie des certificats : installation, renouvellement, révocation via les messages CertificateSigned, InstallCertificate, GetInstalledCertificateIds.

ISO 15118 et Plug & Charge

OCPP 2.0.1 intègre nativement les messages nécessaires au Plug & Charge : le véhicule présente un certificat au lieu d'un badge RFID, la borne le transmet au CSMS pour validation, et la session démarre automatiquement. Les messages Get15118EVCertificate et SignCertificate gèrent l'échange de certificats entre le véhicule, la borne et le CSMS.

Gestion des transactions

Le modèle de transaction change radicalement. En 2.0.1, la transaction est identifiée par un transactionId généré par la borne (UUID), et non plus par le CSMS. Les événements de transaction sont signalés via TransactionEvent (qui remplace StartTransaction, StopTransaction et MeterValues). Chaque événement porte un type (Started, Updated, Ended) et un trigger (Authorized, CablePluggedIn, EVDeparted, etc.).

Ce modèle résout le problème de perte de données en cas de déconnexion : la borne stocke les événements localement et les renvoie au CSMS une fois la connexion rétablie, dans l'ordre chronologique.

Messages d'affichage

La commande SetDisplayMessage permet au CSMS d'envoyer un texte à afficher sur l'écran de la borne. Utile pour informer les utilisateurs d'une maintenance prévue, d'un tarif promotionnel ou d'un message d'urgence. Le message peut être prioritaire, temporaire ou permanent.

Tableau comparatif 1.6 vs 2.0.1

Migration : quand et comment passer en 2.0.1

OCPP 2.0.1 n'est pas rétrocompatible avec 1.6. La structure des messages, les noms des opérations et le modèle de données sont différents. Passer en 2.0.1 nécessite des mises à jour à trois niveaux : le firmware de la borne, le CSMS, et les processus opérationnels.

Prérequis matériels

Toutes les bornes ne sont pas éligibles. OCPP 2.0.1 demande plus de ressources (mémoire, stockage pour les certificats, capacité de calcul pour TLS). Les bornes AC d'entrée de gamme installées avant 2020 ne disposent pas toujours du matériel suffisant. Il faut vérifier auprès du fabricant si un firmware 2.0.1 est disponible pour le modèle concerné.

Cohabitation des versions

La migration se fait rarement en une seule fois. La stratégie la plus courante est la cohabitation :

• Les nouvelles bornes sont configurées en OCPP 2.0.1 dès l'installation
• Les bornes existantes compatibles sont mises à jour par lot, avec validation sur un site pilote
• Les bornes trop anciennes restent en 1.6 jusqu'à leur remplacement
• Le CSMS gère les deux versions en parallèle, chaque borne négociant sa version lors de la connexion WebSocket

Mise à jour firmware

La mise à jour firmware elle-même peut être réalisée à distance via la commande UpdateFirmware (disponible dans les deux versions). Le processus typique : le CSMS envoie l'URL de téléchargement du firmware, la borne le télécharge, vérifie son intégrité, et l'installe lors d'un redémarrage. En 2.0.1, la borne peut signer le firmware et vérifier sa provenance avant installation.

Impact sur l'exploitation quotidienne

Pour les équipes d'exploitation, le passage en OCPP 2.0.1 change plusieurs aspects du travail quotidien.

Diagnostic plus précis

Le device model permet d'identifier exactement quel composant est en défaut. Au lieu d'un StatusNotification générique "Faulted", l'opérateur reçoit une alerte précisant que le compteur d'énergie de l'EVSE 2 renvoie des valeurs incohérentes, ou que le modem 4G a perdu le signal. Cela réduit le temps de diagnostic et permet de préparer l'intervention terrain avec les bonnes pièces.

Monitoring configurable

En 2.0.1, l'opérateur peut définir des seuils de surveillance sur n'importe quelle variable du device model. Par exemple : déclencher une alerte si la température interne de la borne dépasse 55 °C, si la tension réseau sort de la plage 210-240 V, ou si le compteur d'énergie dévie de plus de 2 % par rapport à la valeur attendue. En 1.6, ces seuils n'existent pas dans le protocole et doivent être gérés côté CSMS.

Gestion de l'énergie

Les profils de smart charging sont plus flexibles en 2.0.1. L'opérateur peut définir des limites de puissance au niveau du site (avec répartition automatique entre les EVSE), intégrer des signaux tarifaires dynamiques, et préparer le terrain pour le V2G (Vehicle-to-Grid) quand les véhicules et le cadre réglementaire le permettront.

Communication avec les utilisateurs

La possibilité d'envoyer des messages sur l'écran de la borne simplifie la communication en cas de maintenance programmée ou de tarification spéciale. Plus besoin de coller des affiches physiques sur les bornes.

Questions fréquentes