La référence des protocoles OCPP 2.0.1 et 2.1.
Les 91 messages d’OCPP 2.0.1 et 2.1 avec leurs champs et un exemple, ceux que la 2.1 a ajoutés, le modèle d’équipement qui a pris le relais des clés de configuration de la 1.6, et les trois profils de sécurité.
MessagesModèle d’équipementProfils de sécuritéDepuis la 1.6Questions
Que sont OCPP 2.0.1 et 2.1 ?
Ce sont les versions les plus récentes de l’Open Charge Point Protocol, le standard ouvert de l’Open Charge Alliance qui définit comment une borne communique avec le logiciel qui la gère : le CSMS dans la spécification, le backoffice sur le marché. Comme en 1.6J, la borne ouvre un WebSocket vers le backoffice et les deux côtés s’y envoient des messages JSON.
OCPP 2.0.1 n’est pas rétrocompatible avec la 1.6. Elle décrit une borne comme un modèle d’équipement (device model) fait de composants et de variables, intègre trois profils de sécurité, rapporte une transaction dans un seul message, TransactionEvent, et prend en charge l’ISO 15118 pour Plug and Charge et pour la charge intelligente avec des données de la voiture.
OCPP 2.1 s’appuie sur la 2.0.1. Ses schémas sont ceux de la 2.0.1 avec des champs optionnels en plus, et elle ajoute 27 messages pour la recharge bidirectionnelle, le contrôle DER, les tarifs sur une borne qui calcule elle-même le coût, le paiement à la borne, les flux d’événements périodiques et l’échange de batteries. Une borne et son backoffice conviennent d’une seule version à l’ouverture du WebSocket.
- Un standard ouvertLibre d’implémentation, maintenu par l’Open Charge Alliance. OCPP 2.1 est aussi publiée sous la référence IEC 63584-210.
- WebSocket et JSONUne connexion que la borne garde ouverte. La 2.1 ajoute SEND, un message qui ne reçoit pas de réponse.
- 91 messages64 dans la 2.0.1 et 27 de plus dans la 2.1, répartis en 19 blocs fonctionnels.
- Dans les deux sensLa borne et le backoffice lancent chacun leurs propres messages.
Les 91 messages OCPP 2.0.1 et 2.1
Chaque message est une requête d’un côté et une réponse de l’autre, reliées par un identifiant de message. NotifyPeriodicEventStream est la seule exception : un message SEND de la 2.1 qui ne reçoit pas de réponse.
Sécurité
Les certificats de la borne et du backoffice, et les événements de sécurité que rapporte une borne.
Provisionnement
Le démarrage, l’enregistrement auprès du backoffice, la lecture et le réglage du modèle d’équipement, et les redémarrages.
Autorisation
La vérification d’un jeton d’identification avant la recharge, le cache d’autorisation et, dans la 2.1, le paiement ponctuel.
Liste d’autorisation locale
La liste des jetons d’identification que le backoffice enregistre sur la borne, pour qu’elle puisse autoriser seule.
Transactions
Un seul message, TransactionEvent, pour le début, les mises à jour et la fin de chaque transaction.
Contrôle à distance
Démarrer et arrêter une transaction depuis le backoffice, déverrouiller un point de charge et déclencher un message.
Disponibilité
Le statut de chaque point de charge, le heartbeat, et la mise hors service d’une borne ou d’un EVSE.
Réservation
La réservation d’un EVSE pour un jeton d’identification, et l’annulation de cette réservation.
Tarif et coût
Les prix et le coût en cours pour le conducteur ; dans la 2.1, aussi les tarifs sur une borne qui calcule elle-même le coût.
Valeurs de compteur
Les relevés de compteur en dehors d’une transaction ; pendant une transaction, ils passent par TransactionEvent.
Charge intelligente
Les profils de charge avec des limites de puissance ou de courant, les limites venues de l’extérieur et les besoins du véhicule.
Gestion du firmware
La mise à jour du firmware d’une borne, et sa publication par un contrôleur local.
Gestion des certificats
L’installation et la vérification des certificats, y compris les certificats de contrat de Plug and Charge.
Diagnostic
Les journaux, la surveillance du modèle d’équipement, les événements, les données client et, dans la 2.1, les flux d’événements périodiques.
Messages affichés
Les messages que le backoffice définit pour qu’une borne les affiche aux conducteurs.
Transfert de données
Les données propres au fabricant, pour les fonctions que le standard ne couvre pas.
Transfert d’énergie bidirectionnel
Nouveau en 2.1 : le pilotage de la charge et de la décharge (V2X) par des profils de charge.
Contrôle DER
Nouveau en 2.1 : les réglages de soutien au réseau pour une borne et une voiture qui agissent comme une ressource énergétique distribuée.
Échange de batteries
Nouveau en 2.1 : les stations d’échange de batteries.
Aucun message ne correspond à cette recherche.
Le modèle d’équipement d’OCPP 2.0.1
En OCPP 1.6, une borne a une liste plate de clés de configuration. En 2.0.1 et 2.1, elle se décrit en composants, comme la borne elle-même, un EVSE, un point de charge ou un contrôleur tel que OCPPCommCtrlr, et chaque composant a des variables. Une variable peut contenir quatre valeurs : Actual, Target, MinSet et MaxSet. Ce qui était une clé de configuration est désormais une variable d’un composant contrôleur.
Comment l’utiliser
- GetVariables et SetVariablesLisez ou réglez plusieurs variables dans un seul message. La borne répond pour chaque variable séparément.
- GetBaseReport et GetReportDemandez tout le modèle d’équipement ou une partie. La borne le renvoie dans des messages NotifyReport.
- SurveillanceSetVariableMonitoring surveille une variable selon un seuil, un changement ou un intervalle fixe, et la borne rapporte via NotifyEvent.
- Enabled, par fonctionLe contrôleur d’une fonction optionnelle, comme AuthCacheCtrlr ou ReservationCtrlr, a une variable Enabled qui active ou désactive cette fonction.
Les réponses à SetVariables
- Accepted
- La valeur est définie.
- Rejected
- La variable existe, mais la valeur a été refusée.
- Unknown
Component - La borne n’a pas ce composant.
- Unknown
Variable - Le composant n’a pas cette variable.
- NotSupported
AttributeType - La variable n’a pas de valeur de ce type, par exemple pas de Target.
- RebootRequired
- La valeur est enregistrée et prend effet après un redémarrage.
Les variables qui ont pris le relais des clés 1.6 les plus connues
La spécification en normalise beaucoup d’autres, listées dans ses annexes. Une borne rapporte celles qu’elle possède en réponse à GetBaseReport.
| Composant et variable | Type | Ce qu’elle règle | En OCPP 1.6 |
|---|---|---|---|
| OCPPCommCtrlr | integer, en secondes | Secondes sans autre message après lesquelles la borne envoie un Heartbeat. | Heartbeat |
| OCPPCommCtrlr | integer | Nombre de tentatives de la borne pour remettre un TransactionEvent que le backoffice n’a pas pu traiter. | Transaction |
| OCPPCommCtrlr | integer | Secondes que la borne attend avant de réessayer. | Transaction |
| OCPPCommCtrlr | integer, en secondes | Secondes entre deux pings WebSocket ; 0 désactive les pings de la borne elle-même. | Web |
| OCPPCommCtrlr | integer | Nombre de nouvelles tentatives de la borne après un redémarrage échoué. | Reset |
| OCPPCommCtrlr | boolean | Déverrouiller le câble à la borne quand il est débranché côté voiture. | Unlock |
| SampledDataCtrlr | liste | Ce que la borne mesure pendant une transaction, envoyé dans TransactionEvent avec l’eventType Updated. | Meter |
| SampledDataCtrlr | integer, en secondes | Secondes entre ces relevés ; 0 n’en envoie aucun pendant la transaction. | Meter |
| SampledDataCtrlr | liste | Ce qui figure dans le TransactionEvent qui termine la transaction. | Stop |
| AlignedDataCtrlr | integer, en secondes | Secondes entre deux relevés alignés sur l’horloge. | Clock |
| AlignedDataCtrlr | liste | Ce que contiennent les relevés alignés sur l’horloge. | Meter |
| AlignedDataCtrlr | liste | Relevés alignés sur l’horloge qui figurent dans le TransactionEvent qui termine la transaction. | Stop |
| TxCtrlr | integer, en secondes | Secondes dont dispose un conducteur pour brancher la voiture après le début de la transaction, avant qu’elle ne soit annulée. | Connection |
| TxCtrlr | boolean | Terminer la transaction quand le câble est débranché côté voiture. | Stop |
| TxCtrlr | boolean | Arrêter une transaction en cours quand son jeton d’identification se révèle non accepté. | Stop |
| TxCtrlr | integer | Énergie en Wh que la borne peut encore fournir après que le backoffice a rejeté le jeton d’identification. | Max |
| TxCtrlr | liste | Le moment où une transaction démarre : à l’autorisation, au branchement, quand l’énergie circule, etc. | Nouveau en 2.0.1 |
| TxCtrlr | liste | Le moment où une transaction se termine, choisi dans la même liste. | Nouveau en 2.0.1 |
| AuthCtrlr | boolean | Indique si la borne vérifie d’abord le jeton d’identification d’un démarrage à distance avec un Authorize. | Authorize |
| AuthCtrlr | boolean | Démarrer des transactions hors ligne pour les jetons d’identification qu’elle connaît déjà. | Local |
| AuthCtrlr | boolean | Démarrer pour les jetons d’identification qu’elle connaît déjà, sans attendre le backoffice. | Local |
| AuthCtrlr | boolean | Démarrer des transactions hors ligne pour des jetons d’identification inconnus. | Allow |
| AuthCacheCtrlr | boolean | Utiliser le cache d’autorisation. | Authorization |
| LocalAuthListCtrlr | boolean | Utiliser la liste d’autorisation locale. | Local |
| LocalAuthListCtrlr | integer | Nombre maximal de jetons d’identification dans un seul SendLocalList. | Send |
| SmartChargingCtrlr | integer | Niveau de priorité (stack level) le plus élevé qu’un profil de charge peut avoir. | Charge |
| SmartChargingCtrlr | liste | Indique si les plannings peuvent être en ampères, en watts ou les deux. | Charging |
| SmartChargingCtrlr | integer | Nombre maximal de périodes dans un planning de charge. | Charging |
| SmartChargingCtrlr | boolean | Indique si la borne peut passer de trois phases à une pendant une transaction. | Connector |
| ReservationCtrlr | boolean | Indique si une réservation peut porter sur la borne dans son ensemble plutôt que sur un seul EVSE. | Reserve |
Aucune variable ne correspond à cette recherche.
Profils de sécurité d’OCPP 2.0.1 et 2.1
Les deux versions définissent trois profils de sécurité. Une borne et son backoffice en utilisent un à la fois, et il est fixé avant le premier message OCPP. Le backoffice le définit par emplacement de connexion avec SetNetworkProfile, et la borne rapporte celui qu’elle utilise dans SecurityCtrlr.SecurityProfile.
| Profil | Comment la borne prouve son identité | Comment le backoffice prouve son identité | La connexion |
|---|---|---|---|
| 1. Transport non sécurisé avec authentification basique | Authentification HTTP Basic, avec un mot de passe | Il ne la prouve pas | Non chiffrée. Uniquement pour les réseaux de confiance, comme un VPN entre la borne et le backoffice. |
| 2. TLS avec authentification basique | Authentification HTTP Basic, avec un mot de passe | Son certificat serveur TLS | TLS 1.2 ou supérieur |
| 3. TLS avec certificats côté client | Son propre certificat client TLS | Son certificat serveur TLS | TLS 1.2 ou supérieur |
- RétrograderUne borne ne peut passer que du profil 3 au profil 2, et seulement quand AllowSecurityProfileDowngrade est réglé sur true. Elle ne redescend jamais au profil 1 via OCPP.
- Mots de passe et certificatsLe mot de passe est SecurityCtrlr.BasicAuthPassword. La borne demande un nouveau certificat avec SignCertificate, et le backoffice le remet avec CertificateSigned.
- Événements de sécuritéLa borne rapporte ce qui s’est passé, comme un redémarrage, une mise à jour du firmware ou des identifiants refusés par le backoffice, avec SecurityEventNotification.
D’OCPP 1.6 à 2.0.1, message par message
OCPP 2.0.1 a conservé beaucoup de noms de messages de la 1.6, et en a renommé ou fusionné d’autres. Un lien ouvre le message dans cette référence ou dans la référence 1.6J.
| OCPP 1.6 | OCPP 2.0.1 et 2.1 | Ce qui a changé |
|---|---|---|
| StartTransaction, StopTransaction | TransactionEvent | Un seul message avec l’eventType Started, Updated ou Ended. La borne définit l’ID de transaction, une chaîne. |
| MeterValues | TransactionEvent, MeterValues | Les relevés pendant une transaction passent par TransactionEvent ; MeterValues transporte les relevés en dehors d’une transaction. |
| StatusNotification | StatusNotification, NotifyEvent | StatusNotification ne rapporte plus que le statut du point de charge, avec evseId et connectorId. Les codes d’erreur passent par NotifyEvent, et la 2.1 privilégie aussi NotifyEvent pour la disponibilité. |
| RemoteStartTransaction | RequestStartTransaction | Transporte un objet idToken et un remoteStartId, qui revient dans le TransactionEvent qui démarre la transaction. |
| RemoteStopTransaction | RequestStopTransaction | Arrête une transaction par son ID, qui est désormais une chaîne. |
| ChangeConfiguration | SetVariables | Règle plusieurs variables du modèle d’équipement dans un seul message. |
| GetConfiguration | GetVariables, GetBaseReport, GetReport | Lit des variables choisies, ou demande un rapport qui arrive dans des messages NotifyReport. |
| GetDiagnostics | GetLog | Demande un journal de diagnostic ou un journal de sécurité. |
| DiagnosticsStatusNotification | LogStatusNotification | Rapporte l’avancement de cet envoi. |
| Reset | Reset | Immediate ou OnIdle à la place de Hard ou Soft, et il peut redémarrer un seul EVSE. |
| ChangeAvailability | ChangeAvailability | Cible la borne, un EVSE ou un point de charge via son champ evse. |
| Authorize | Authorize | Un objet idToken avec un type, à la place de la chaîne idTag. |
| BootNotification | BootNotification | Ajoute la raison du démarrage ; les informations de la borne se trouvent dans un objet chargingStation. |
| Heartbeat, UnlockConnector, ClearCache, DataTransfer, ReserveNow, CancelReservation, SendLocalList, GetLocalListVersion, SetChargingProfile, ClearChargingProfile, GetCompositeSchedule, TriggerMessage, UpdateFirmware, FirmwareStatusNotification | Les mêmes noms | Les mêmes messages, avec des champs pour les EVSE et les types de données plus récents. |
Questions sur OCPP 2.0.1 et 2.1
La version 2.0.1 de l’Open Charge Point Protocol, publiée par l’Open Charge Alliance en 2020. Elle a remplacé OCPP 2.0 et, par rapport à la 1.6, ajoute le modèle d’équipement, les profils de sécurité, la prise en charge de l’ISO 15118 et TransactionEvent. Elle n’est pas rétrocompatible avec la 1.6.
OCPP 2.1 a été publiée en janvier 2025 et constitue aussi la norme IEC 63584-210. Elle ajoute 27 messages et n’en retire aucun : la recharge bidirectionnelle (V2X) et le contrôle DER, l’ISO 15118-20, les tarifs sur une borne qui calcule elle-même le coût, le paiement à la borne avec un terminal de paiement par carte ou un QR code, la charge prioritaire, les profils de charge dynamiques, les flux d’événements périodiques et l’échange de batteries. Choisissez Nouveau en 2.1 au-dessus des messages pour les voir.
Les schémas de la 2.1 sont ceux de la 2.0.1 avec des champs optionnels en plus et, selon l’Open Charge Alliance, une logique écrite pour la 2.0.1 continue de fonctionner moyennant deux petites modifications : SignCertificate peut transporter un requestId que CertificateSigned répète ensuite, et NotifyMonitoringReport a un nouveau champ obligatoire. La version se négocie toujours par connexion : lors du handshake WebSocket, la borne propose par exemple ocpp2.1, ocpp2.0.1 et ocpp1.6, et le backoffice en choisit une.
La 2.0.1 a son propre jeu de messages : un modèle d’équipement à la place des clés de configuration, des profils de sécurité, TransactionEvent à la place de StartTransaction et StopTransaction, l’EVSE comme niveau entre la borne et ses points de charge, et des messages pour l’ISO 15118. Une borne et son backoffice conviennent d’une seule version à l’ouverture de la connexion. Le tableau ci-dessus met les messages en correspondance, et la référence OCPP 1.6J contient tous les messages 1.6.
Après la sortie d’OCPP 2.0, des problèmes sont apparus qui ne pouvaient être corrigés qu’en modifiant les schémas des messages, ce qu’une implémentation 2.0 ne pouvait pas suivre. L’Open Charge Alliance a donné à la version corrigée son propre numéro, 2.0.1, et conseille de n’implémenter que la 2.0.1. Dans la spécification, OCPP 2.0 désigne la 2.0.1, sauf mention contraire.
L’Open Charge Alliance publie les deux gratuitement sur son site web, avec un schéma JSON pour chaque message et une liste d’errata. Cette référence suit les schémas JSON et la partie 2 de la spécification. Là où les deux diffèrent, ce sont la spécification et ses errata qui font foi.
Cherchez-la dans la base de données des bornes : 102 bornes y indiquent OCPP 2.0.1 et 4 indiquent la 2.1. La fiche technique l’indique généralement aussi. Une borne qui prend en charge plusieurs versions les propose toutes à la connexion, et le backoffice en choisit une.
OCPP 1.6J sur Plugchoice
Plugchoice connecte aujourd’hui les bornes OCPP 1.6J, selon le modèle, le firmware et la configuration.