Tester la connectivité OCPI et OCPP

OCPP : de la borne au CPMS

Les tests de conformité OCPP doivent couvrir tout le cycle de vie de la session, pas seulement le scénario idéal. Une séquence minimale :

1. Démarrage et handshake. BootNotification est accepté, et la borne applique correctement toute configuration renvoyée en réponse.
2. Autorisation. Les flux de démarrage à distance et par badge/carte réussissent tous deux, y compris avec un badge délibérément invalide pour confirmer que le rejet est géré proprement.
3. Cycle de vie de la transaction. StartTransaction, MeterValues à l'intervalle configuré, et StopTransaction rapportent tous des valeurs d'énergie cohérentes et non nulles, qui se réconcilient avec une lecture de compteur physique.
4. Gestion des pannes. Simulez une panne de connecteur en cours de session et confirmez que la borne rapporte correctement StatusNotification et que le CPMS réagit (alerte, fin de session) plutôt que d'afficher un état « en charge » obsolète.
5. Perte de connectivité. Déconnectez la liaison réseau en cours de session, confirmez le comportement d'autorisation hors ligne, puis reconnectez et confirmez que le CPMS réconcilie la session plutôt que de la perdre.
6. Déploiement de firmware et de configuration. Confirmez qu'un changement de configuration à distance et une mise à jour de firmware se terminent tous deux sans corrompre l'état de session sur des connecteurs non concernés.

Testez avec la version OCPP exacte parlée par le CPMS (1.6J et 2.0.1 ne sont pas interchangeables en pratique) et enregistrez les échanges de messages bruts pendant les tests — un test réussi sans journal de messages n'est pas reproductible quand une panne réapparaît en production des mois plus tard.

OCPI : itinérance CPO vers eMSP

Les tests OCPI doivent être validés dans les deux sens de la relation d'itinérance :

• Synchronisation des emplacements et du statut. Confirmez que la vue de l'eMSP sur la disponibilité du site correspond au statut réel en temps réel du CPO, y compris après qu'un connecteur passe hors ligne — un décalage de synchronisation ici est une cause majeure de plaintes de conducteurs sur les sessions en itinérance.
• Propagation des tarifs. Confirmez que le prix affiché à un conducteur en itinérance avant de démarrer une session correspond à ce qui est réellement facturé, y compris les composantes de tarification horaire et de frais d'immobilisation.
• Précision des CDR (Charge Detail Record). Réconciliez un échantillon de CDR avec les propres données de mesure du CPO avant la mise en service d'un nouveau partenaire d'itinérance — les écarts ici deviennent des litiges de facturation.
• Commandes de session. Le démarrage/arrêt à distance initié par l'eMSP atteint correctement la borne physique et reflète l'état réel, pas seulement un accusé de réception au niveau de l'API.

Une remarque sur les déclarations « conforme »

Réussir une suite de tests de conformité automatisée est nécessaire mais pas suffisant. Cela valide la structure et le séquencement des messages ; cela ne valide pas qu'une borne se comporte correctement dans les conditions de connectivité et de charge d'un déploiement spécifique. Les tests au niveau du site après les tests de conformité ne sont pas redondants — c'est l'étape qui détermine réellement si une borne tiendra en production.