OCPP 1.6 face à 2.0.1
La 2.0.1 n’est pas la 1.6 avec davantage de messages. Elle restructure la configuration, les transactions et la sécurité, et les deux ne sont compatibles sur le fil dans aucun sens.
Les deux versions partagent un transport — OCPP-J sur WebSocket — et un mécanisme de négociation de sous-protocole, et c’est à peu près là que s’arrête la ressemblance. Une borne annonce ocpp1.6 ou ocpp2.0.1 dans Sec-WebSocket-Protocol, et un CSMS qui prend en charge les deux fait tourner deux implémentations distinctes derrière ce choix.
OCPP 1.6 reste la version que parle la majorité du matériel déployé. La 2.0.1 est ce que les nouveaux appels d’offres exigent de plus en plus. La plupart des exploitants font tourner les deux pendant des années, et c’est la raison pratique pour laquelle cette comparaison compte.
Équivalences de messages
Où est passé chaque message 1.6 en 2.0.1. Ce n’est pas un chemin de migration — les charges utiles diffèrent même quand le nom survit.
| OCPP 1.6 | OCPP 2.0.1 | Ce qui a changé |
|---|---|---|
Authorize | Authorize | Même finalité. `idTag` devient l’objet structuré `idToken`. |
BootNotification | BootNotification | `chargePointVendor`/`chargePointModel` passent dans un objet `chargingStation`. |
Heartbeat | Heartbeat | Finalité inchangée. |
StartTransaction | TransactionEvent | Démarrage, arrêt et mises à jour fusionnent en un seul message doté d’un `eventType`. |
StopTransaction | TransactionEvent | Idem — `eventType: "Ended"`. |
MeterValues | TransactionEvent | Les données de compteur circulent dans TransactionEvent pendant une session. |
StatusNotification | StatusNotification | Rapporte désormais par EVSE et par connecteur plutôt que par un identifiant de connecteur à plat. |
ChangeConfiguration | SetVariables | Les clés de chaîne à plat deviennent des variables adressées dans le modèle d’équipement. |
GetConfiguration | GetVariables | Même changement, en lecture plutôt qu’en écriture. |
GetDiagnostics | GetLog | Généralisé : journaux de diagnostic et journaux de sécurité. |
ReserveNow | ReserveNow | La réservation fait désormais partie du cœur plutôt que d’un profil optionnel. |
Le modèle d’équipement
C’est le changement dont tout le reste découle. La configuration OCPP 1.6 est une table plate de clés de chaîne — HeartbeatInterval, MeterValueSampleInterval — et les capacités d’une borne se réduisent aux clés qu’elle possède.
La 2.0.1 remplace cela par un modèle d’équipement structuré : composants, variables et attributs avec types et contraintes. Un CSMS peut demander à une borne de se décrire elle-même, au lieu de sonder des clés en espérant.
C’est une véritable amélioration, et c’est aussi la plus grosse source de travail de migration, car rien de la surface de configuration 1.6 ne se reporte.
Les transactions sont devenues un seul message
En 1.6, une session est StartTransaction, puis MeterValues, puis StopTransaction — trois types de messages avec des règles de corrélation distinctes et un transactionId attribué par le serveur.
En 2.0.1, les trois deviennent TransactionEvent avec un eventType valant Started, Updated ou Ended, et c’est la borne qui génère elle-même l’identifiant de transaction. La gestion hors ligne s’en trouve nettement simplifiée, car la borne n’a jamais à attendre que le serveur nomme une session qu’elle a déjà commencée.
La sécurité est spécifiée, pas supposée
OCPP 1.6 ne dit pratiquement rien sur la sécurité. TLS est une recommandation, l’authentification est hors périmètre, et en pratique les déploiements vont du ws:// en clair au TLS mutuel.
La 2.0.1 définit trois profils de sécurité : HTTP Basic sur TLS, TLS avec certificat client, et TLS avec authentification mutuelle par certificat, ainsi que des messages de gestion de certificats pour les renouveler. Pour quiconque a déjà dû répondre à un questionnaire de sécurité sur un réseau de recharge, c’est la partie la plus précieuse de la montée de version.
EVSE et connecteur sont désormais distincts
La 1.6 numérote les connecteurs à partir de 1, le 0 désignant la borne entière. Ce modèle plat ne sait pas exprimer une station où deux connecteurs partagent un même module de puissance et ne peuvent pas recharger simultanément à pleine puissance.
La 2.0.1 introduit l’EVSE comme niveau explicite entre la station et le connecteur, et c’est ce qui rend possible une répartition de charge correcte sur du matériel multi-prises.
La recharge intelligente est devenue plus capable et plus complexe
Les profils de charge existent dans les deux. La 2.0.1 ajoute des limites de charge issues du système local de gestion de l’énergie, la prise en charge d’ISO 15118 pour le plug-and-charge et les flux bidirectionnels, et une notion bien plus riche de ce qui peut contraindre une session.
Si votre recharge intelligente 1.6 fonctionne, les concepts se transposent. Les charges utiles, non.
Laquelle implémenter ?
Si vous développez le micrologiciel d’un matériel qui sort cette année, la 1.6 reste ce à quoi la plupart des réseaux le connecteront, et la 2.0.1 est ce qu’une part croissante d’appels d’offres demande. Construire la couche protocole derrière une abstraction — plutôt que de faire circuler des types de messages OCPP à travers votre logique métier — est ce qui rend la prise en charge des deux abordable.
Si vous construisez un CSMS, il vous faudra les deux, car les parcs de vos clients contiendront les deux pour un bon moment.
Dans les deux cas, le coût de migration se concentre sur la configuration et les transactions, pas sur le transport. Prévoyez le budget pour le modèle d’équipement.
L’ensemble des messages 1.6 est documenté dans notre référence OCPP 1.6, et OcppPilot implémente les deux versions derrière une seule interface Go.