Standarder och implementeringsvägledning
Testa OCPI- och OCPP-anslutning
En protokollimplementation som klarar en demo och misslyckas i produktion har oftast misslyckats med att testa de vägar som bara uppstår under verkliga förhållanden: avbrott, återförsök och partiella meddelanden.
OCPP: laddare till CPMS
OCPP-konformitetstestning bör täcka hela sessionens livscykel, inte bara den enkla vägen. En minsta sekvens:
- Uppstart och handskakning. BootNotification accepteras, och laddaren tillämpar korrekt eventuell konfiguration som skickas som svar.
- Auktorisering. Både fjärrstart och kort-/tagg-flöden lyckas, inklusive en avsiktligt ogiltig tagg för att bekräfta att avvisning hanteras korrekt.
- Transaktionslivscykel. StartTransaction, MeterValues med konfigurerat intervall, och StopTransaction rapporterar alla konsekventa, icke-nollställda energivärden som stämmer överens med en fysisk mätaravläsning.
- Felhantering. Simulera ett kontaktfel mitt i en session och bekräfta att laddaren rapporterar StatusNotification korrekt och att CPMS:et reagerar (larm, sessionsavslut) i stället för att visa ett inaktuellt "laddar"-tillstånd.
- Förlorad anslutning. Koppla bort uppkopplingen mitt i en session, bekräfta offline-auktorisering/lokalt beteende, återanslut sedan och bekräfta att CPMS:et stämmer av sessionen i stället för att förlora den.
- Firmware- och konfigurationsutrullning. Bekräfta att både en fjärrkonfigurationsändring och en firmware-uppdatering slutförs utan att förstöra sessionstillstånd på orelaterade kontakter.
Testa mot den specifika OCPP-version som CPMS:et talar (1.6J och 2.0.1 är inte utbytbara i praktiken) och logga rå meddelandeutväxling under testningen — ett godkänt test utan meddelandelogg går inte att återskapa när ett fel dyker upp igen i produktion månader senare.
OCPI: roaming från CPO till eMSP
OCPI-testning behöver valideras från båda riktningarna i roamingrelationen:
- Synk av plats och status. Bekräfta att eMSP:ns vy av platsens tillgänglighet matchar CPO:ns faktiska realtidsstatus, även efter att en kontakt går offline — synkfördröjning här är en ledande orsak till förarklagomål vid roamade sessioner.
- Taxeöverföring. Bekräfta att priset som visas för en roamande förare innan en session startar matchar vad som faktiskt debiteras, inklusive tidsbaserade och stilleståndsavgiftskomponenter.
- CDR-noggrannhet (Charge Detail Record). Stäm av ett urval CDR:er mot CPO:ns egen mätdata innan lansering med en ny roamingpartner — avvikelser här blir faktureringstvister.
- Sessionskommandon. Fjärrstart/-stopp initierat av eMSP:n når korrekt den fysiska laddaren och återspeglar verkligt tillstånd, inte bara en bekräftelse på API-nivå.
En anmärkning om "konform"-påståenden
Att klara en automatiserad konformitetstestsvit är nödvändigt men inte tillräckligt. Det validerar meddelandestruktur och sekvensering; det validerar inte att en laddare beter sig korrekt under anslutnings- och lastförhållandena i en specifik driftsättning. Testning på platsnivå efter konformitetstestning är inte redundant — det är steget som faktiskt avgör om en laddare håller i produktion.