OCPI 2.2.1 — Comment ça marche (vue d'ensemble ChargeMSI ⇄ Gireve)

Cette page est une lecture fonctionnelle : aucune ligne de code, juste de quoi comprendre les rôles, les modules, et la séquence des échanges.

---

1. Les rôles

Rôle	Qui ?	Rôle technique
CPO (Charge Point Operator)	ChargeMSI	exploite les bornes physiques (OCPP). Expose ses bornes, sessions, CDR, tarifs.
EMSP (E-Mobility Service Provider)	Opérateurs de mobilité (clients finaux)	possède les tokens (badges, app), demande des sessions.
Hub	Gireve	aiguilleur entre N CPOs et M EMSPs. ChargeMSI ne parle QU'à Gireve.

2. Les modules

Module	SENDER	RECEIVER	Côté ChargeMSI
locations	CPO	EMSP/Hub	SENDER
sessions	CPO	EMSP/Hub	SENDER
cdrs	CPO	EMSP/Hub	SENDER
tariffs	CPO	EMSP/Hub	SENDER
tokens	EMSP/Hub	CPO	RECEIVER
commands	EMSP/Hub	CPO	RECEIVER
credentials	les deux	les deux	les deux
versions	tous	tous	les deux

Mnémotechnique : Locations / Sessions / CDRs / Tariffs partent de nous ; Tokens / Commands arrivent chez nous.

3. Cycle de vie d'une session OCPI

EMSP / Hub                                    ChargeMSI (CPO)
   │                                                 │
   │  1. POST /tokens/.../authorize                  │
   ├────────────────────────────────────────────────►│   ── ChargeTag check
   │  ◄────── AuthorizationInfo (ALLOWED)            │
   │                                                 │
   │  2. POST /commands/START_SESSION                │
   ├────────────────────────────────────────────────►│   ── enqueue OCPP RemoteStart
   │  ◄────── CommandResponse (ACCEPTED)             │
   │                                                 │
   │  3. POST {response_url} CommandResult (ACCEPTED)│   ── (worker) résultat async
   │  ◄──────────────────────────────────────────────┤
   │                                                 │
   │  4. PUT /sessions/FR/MSI/{id} (ACTIVE)          │   ── pendant la charge
   │  ◄──────────────────────────────────────────────┤
   │                                                 │
   │  5. PUT /sessions/FR/MSI/{id} (COMPLETED)       │   ── StopTransaction OCPP
   │  ◄──────────────────────────────────────────────┤
   │                                                 │
   │  6. POST /cdrs (CDR immutable)                  │   ── facturation OCPI figée
   │  ◄──────────────────────────────────────────────┤

Étapes 4–6 : asynchrones, écrites dans ocpi.OutboundMessages (outbox), envoyées par OcpiOutboundDispatcherService du Worker.

4. Sécurité — les trois tokens OCPI

OCPI utilise un token statique base64 : Authorization: Token <base64>.

Token	Émetteur	Rôle	Durée
TOKEN_TEMPORAIRE_CHARGEMSI	ChargeMSI	premier appel entrant de Gireve vers POST /credentials	Jetable
TOKEN_GIREVE	Gireve	appels sortants ChargeMSI vers Gireve apres le handshake	Permanent (rotation possible)
TOKEN_CHARGEMSI_FINAL	ChargeMSI	appels entrants Gireve vers ChargeMSI apres le handshake	Permanent (rotation possible)

Voir first-registration.md pour la séquence détaillée.

5. Enveloppe de réponse OCPI

{
  "data":            { ... },
  "status_code":     1000,
  "status_message":  "Success",
  "timestamp":       "2026-05-13T10:32:11.123Z"
}

Les codes de statut OCPI sont distincts des codes HTTP. Un appel peut renvoyer HTTP 200 avec un status_code: 2001 (paramètres invalides). Voir Models/OcpiStatusCodes.cs :

• 1xxx succès
• 2xxx erreur client
• 3xxx erreur serveur
• 4xxx erreur hub

6. Identifiants stables

Objet OCPI	Construction
Location.id	ChargePoint.ChargePointId
EVSE.uid	FR*MSI*E{ChargePointId}*{ConnectorId}
Connector.id	ConnectorId
Session.id	Transaction.TransactionId
Cdr.id	CDR-{Transaction.TransactionId}
Tariff.id	TariffProfile.Id

Ne jamais changer ces formules sans plan de migration.