Les modules OCPI 2.2.1 expliqués : Locations, Sessions, CDR, Tariffs et plus

OCPI (Open Charge Point Interface) est le protocole avec lequel réseaux de recharge et opérateurs de mobilité échangent localisations, sessions, prix et enregistrements de facturation. La version 2.2.1 est aujourd'hui la plus déployée en Europe. Si vous connectez un CSMS à un partenaire d'itinérance ou à une plateforme, vous passerez l'essentiel de votre temps dans ses modules.

Ce guide détaille chaque module, qui envoie et qui reçoit les données, et où les intégrations échouent le plus souvent. Pour une vue d'ensemble, lisez d'abord ce qu'est OCPI et sa différence avec OCPP.

Organisation d'OCPI 2.2.1

OCPI est un protocole REST/JSON. Chaque partie expose des points d'accès HTTPS et appelle ceux de l'autre. Les modules sont regroupés par usage et implémentés sous forme de paire d'interfaces : le Sender possède la donnée, le Receiver la stocke ou agit en conséquence. Un CPO est par exemple Sender pour Locations et Receiver pour Tokens.

La version 2.2 a introduit la prise en charge explicite des plateformes, des rôles et de nouveaux modules ; la 2.2.1 a corrigé et clarifié la 2.2. Des versions ultérieures comme la 2.3.0 ajoutent des fonctions, mais la 2.2.1 reste la base commune entre plateformes et partenaires.

Modules de configuration

Versions

Le module Versions indique au partenaire les versions d'OCPI que vous gérez et, pour chacune, la liste des points d'accès et leurs rôles. C'est toujours le premier appel d'une intégration.

Credentials et enregistrement

Credentials établit le lien sécurisé. La partie A reçoit un jeton (souvent appelé Token A) par un autre canal, appelle le point Versions de la partie B et envoie en POST ses propres identifiants avec un nouveau Token B. La partie B répond avec un Token C, que A utilise ensuite pour tous les appels. L'objet Credentials liste aussi les rôles de chaque partie, CPO, EMSP ou HUB, avec code pays et identifiant de partie.

Les modules fonctionnels en bref

Locations

Locations suit une hiérarchie à trois niveaux : une Location (le site) contient des EVSE, et chaque EVSE des connecteurs. Les EVSE portent le statut visible dans les applications, comme AVAILABLE, CHARGING ou OUTOFORDER, et doivent avoir un identifiant EVSE correctement formaté. Les connecteurs décrivent norme, format, type de courant, tension, intensité et tarifs applicables.

Poussez les changements de statut dès qu'ils surviennent. Une borne affichée disponible chez un partenaire alors qu'elle est en panne génère conducteurs mécontents et tickets de support.

Sessions

Le module Sessions permet à l'eMSP de montrer la progression en direct : kWh délivrés, heure de début et coût à l'instant. Le CPO crée la session au démarrage et la met à jour pendant la charge. Les sessions ne servent pas à facturer : c'est le rôle des CDR.

CDRs

Un CDR est l'enregistrement définitif et immuable d'une session : identité, lieu, début et fin, énergie, périodes de charge, tarifs appliqués et coût total. Il est créé une fois et jamais modifié ; une correction passe par un CDR d'avoir. Notre guide des enregistrements de recharge approfondit ce point.

Tariffs

Tariffs décrit des composantes de prix telles qu'ENERGY, TIME, PARKING_TIME et FLAT, avec des restrictions par heure, jour de la semaine, kWh minimum ou maximum et plages de puissance. Cette structure est puissante mais facile à mal employer. Publiez des tarifs qui reproduisent exactement ce que vous facturez, sinon vos partenaires contesteront les CDR. Pour la conception commerciale, voir les modèles tarifaires.

Tokens

Tokens est la liste des identifiants conducteurs valides de l'eMSP, généralement des UID RFID et des jetons d'application. Le CPO peut les mettre en cache pour autoriser rapidement, et demander une autorisation en temps réel pour un jeton inconnu. Un bon CSMS s'appuie sur ce cache quand le partenaire est lent ou hors ligne, en complément de la logique d'autorisation RFID de la borne.

Commands

Commands permet à un eMSP de demander au CPO START_SESSION, STOP_SESSION, RESERVE_NOW, CANCEL_RESERVATION ou UNLOCK_CONNECTOR. Les commandes sont asynchrones : le CPO confirme d'abord la prise en compte, puis publie le résultat réel sur une URL de réponse quand la borne a répondu. En interne, le CSMS les traduit en messages OCPP comme RemoteStartTransaction.

ChargingProfiles

ChargingProfiles permet à un fournisseur de recharge intelligente de fixer une limite sur une session active, de lire le profil actif ou de le supprimer. Les résultats sont là encore asynchrones. C'est utile lorsqu'un service énergétique, et non le CPO, optimise la recharge.

HubClientInfo

Si vous êtes connecté via une plateforme, HubClientInfo indique quelles autres parties sont connectées et joignables. Utilisez-le pour éviter d'envoyer des requêtes à des partenaires hors ligne.

Push, pull et pagination

La plupart des modules gèrent le push (le Sender appelle le Receiver à chaque changement) et le pull (le Receiver récupère périodiquement les listes). Le pull utilise date_from, date_to, offset et limit, la pagination étant renvoyée dans les en-têtes Link, X-Total-Count et X-Limit. Utilisez le push pour le temps réel et le pull comme filet de sécurité pour les messages manqués.

Codes de statut OCPI

Pièges d'intégration fréquents

• Encodage du jeton : OCPI 2.2 attend un jeton encodé en Base64 dans l'en-tête Authorization ; une erreur provoque des 401 silencieux.
• Fuseaux horaires : tous les horodatages sont en UTC ; les horaires locaux relèvent du champ fuseau de la Location.
• Identifiants de partie : code pays et identifiant doivent concorder sur chaque objet, sinon les partenaires rejettent.
• Écarts tarifaires : un montant de CDR impossible à recalculer depuis le tarif publié entraîne des litiges.
• Absence de relance : un push échoué doit être réessayé et des pulls périodiques doivent combler les trous.

Questions fréquentes

Üreticy prend en charge l'itinérance OCPI en plus d'OCPP 1.6J, 2.0.1 et 2.1, avec des journaux complets par partenaire. Découvrir la plateforme ou parler à notre équipe.