OCPP 2.0.1 : une revolution silencieuse pour le terrain
Le protocole OCPP (Open Charge Point Protocol) est le standard de communication entre les bornes de recharge et les systèmes de supervision (CSMS). La version 2.0.1, ratifiée par l’Open Charge Alliance, apporte des changements majeurs qui impactent directement le travail des techniciens terrain. Voici ce qu’il faut savoir.
Rappel : OCPP 1.6 vs 2.0.1, les différences clés
Le passage de OCPP 1.6 à 2.0.1 n’est pas une simple mise à jour — c’est une refonte complète du protocole :
| Aspect | OCPP 1.6 | OCPP 2.0.1 |
|---|---|---|
| Modele de données | Plat (charge point) | Hierarchique (composants, variables, EVSE) |
| Sécurité | Basique (auth simple) | Avancee (TLS mutuel, certificats) |
| Device Management | GetConfiguration / ChangeConfiguration | GetVariables / SetVariables / GetBaseReport |
| Monitoring | Limité (StatusNotification) | Étendu (monitoring events, alertes custom) |
| Smart Charging | Profils basiques | ISO 15118, Plug & Charge, V2G ready |
| Diagnostics | GetDiagnostics (fichier) | LogStatusNotification + CustomerInformation |
| Transactions | StartTransaction / StopTransaction | TransactionEvent (événementiel) |
| Firmware | UpdateFirmware simple | SignedUpdateFirmware (sécurisé) |
Ce qui change concretement pour le technicien
1. Un diagnostic à distance beaucoup plus puissant
Avant (OCPP 1.6) : Le diagnostic à distance se limitait a lire le StatusNotification (Available, Faulted, etc.) et a récupérer un fichier de diagnostic via GetDiagnostics. Peu d’information en temps réel.
Maintenant (OCPP 2.0.1) : Le nouveau système de monitoring permet de :
- Définir des seuils d’alerte sur n’importe quelle variable (température, tension, courant, nombre d’erreurs)
- Recevoir des notifications proactives quand un seuil est dépasse (MonitoringEvent)
- Acceder à l’arborescence complète des composants de la borne (EVSE > Connector > Controller > PowerModule)
Concretement, avant de vous déplacer, vous savez exactement quel composant est en défaut et pourquoi. Le DMT s’en trouve considérablement réduit.
2. La sécurité renforcée : plus de certificats a gerer
OCPP 2.0.1 introduit la gestion des certificats TLS pour sécuriser les communications. Pour le technicien, cela signifie :
Nouveaux gestes techniques :
- Installation de certificats client sur la borne (lors de la mise en service)
- Renouvellement des certificats (automatique ou manuel)
- Diagnostic des problèmes de connexion liés àux certificats (expiration, révocation)
Commandes OCPP liées :
- InstallCertificate : installer un certificat racine
- GetInstalledCertificateIds : lister les certificats installés
- DeleteCertificate : supprimer un certificat
- CertificateSigned : confirmer la signature d’un CSR
En pratique : Si une borne ne se connecte plus au CSMS après une mise à jour, le premier réflexe est de vérifier les certificats TLS. C’est un nouveau type de panne qui n’existait pas en OCPP 1.6.
3. Le modèle de données hierarchique : comprendre les composants
OCPP 2.0.1 modèle la borne de façon hierarchique :
ChargingStation
|-- EVSE 1
| |-- Connector 1 (CCS2)
| |-- Connector 2 (CHAdeMO)
|-- EVSE 2
| |-- Connector 1 (Type 2)
|-- Controller
|-- PowerModule 1
|-- PowerModule 2
|-- NetworkModule
|-- DisplayModule
Chaque composant à ses propres variables (température, firmware version, error count, etc.). Quand vous faites un GetVariables, vous pouvez cibler un composant spécifique.
Impact pour le technicien : Vous pouvez diagnostiquer à distance quel module de puissance est défaillant dans une borne multi-EVSE, sans avoir à tout tester sur place.
4. Les mises à jour firmware sécurisées
OCPP 1.6 : UpdateFirmware envoyait une URL de téléchargement. Pas de vérification d’intégrité.
OCPP 2.0.1 : SignedUpdateFirmware ajoute :
- Signature numérique du firmware
- Vérification d’intégrité avant installation
- Rollback automatique en cas d’échec
Pour le technicien : Moins de risques de "bricker" une borne avec un firmware corrompu. Mais il faut comprendre le processus de signature et savoir réagir si la vérification echoue.
5. Plug & Charge et ISO 15118
OCPP 2.0.1 est conçu pour supporter le Plug & Charge (ISO 15118-2) :
- L’utilisateur branche son véhicule et la charge démarre automatiquement
- Authentification par certificat véhicule (pas de badge, pas de QR code)
- Communication haute-level entre le véhicule et la borne
Impact maintenance :
- Nouveau type de panne : "le Plug & Charge ne fonctionne pas" (problème de certificat véhicule, de root CA, de communication HLC)
- Outils de diagnostic spécifiques (analyseur ISO 15118)
- Formation nécessaire sur le protocole véhicule-borne
6. Smart Charging avancé
OCPP 2.0.1 enrichit considérablement les profils de charge :
- Profils externes : contraintes du gestionnaire de réseau
- Profils station : limites de puissance du site
- Profils transaction : preferences du conducteur
- Priorités : gestion des conflits entre profils
Pour le technicien : Quand un utilisateur se plaint que "la borne ne charge pas à pleine puissance", il faut désormais vérifier les profils de charge actifs (GetCompositeSchedule). La limitation peut venir du réseau, du site, ou du contrat de l’utilisateur.
Comment se préparer a OCPP 2.0.1 ?
- Formation : suivre les webinaires de l’Open Charge Alliance
- Pratique : tester sur des bornes compatibles (Kempower, Alpitronic et ABB supportent déjà 2.0.1)
- Outils : s’equiper de logiciels de diagnostic compatibles 2.0.1
AIXO intègre nativement les deux versions du protocole (1.6 et 2.0.1) et adapté ses procédures de diagnostic en fonction de la version OCPP de la borne. L’IA vous guide sur les nouvelles commandes et les nouveaux types de pannes spécifiques à 2.0.1.
Maîtrisez OCPP 2.0.1 avec AIXO.
👉 Essayer l’assistant sans compte · Créer un compte : 7 jours d’essai sans carte bancaire · Voir les tarifs