OCPP-interoperabiliteitstesten

Dekking

• Opstarten, registratie en uitwisseling van configuratie
• Heartbeat en gedrag bij verlies en herstel van de verbinding
• Volledige levenscyclus van transacties, inclusief gelijktijdige en onderbroken sessies
• Meetwaarden: eenheden, contexten, intervallen en bruikbaarheid voor facturatie
• Starten, stoppen, resetten en ontgrendelen op afstand, gecontroleerd aan het laadstation en niet alleen op protocolniveau
• Firmwarebeheer, inclusief statusrapportage tot en met voltooiing
• Beschikbaarheid, reservering en profielen voor slim laden voor zover opgenomen in de scope
• Herstel na fouten: herstart van het laadstation, herstart van het platform en afwijking van de klok

Negatieve en onderbroken scenario's

De belangrijkste tests zijn de scenario's waarin halverwege iets misgaat. Verbreek het netwerk tijdens een actieve transactie. Start het laadstation opnieuw op terwijl een sessie nog openstaat. Stuur een opdracht die het laadstation weigert. Wat beide systemen daarna doen, bepaalt of transacties in een operationele vloot factureerbaar blijven.

Testbewijs

Iedere test levert een vastgelegde berichtenuitwisseling op, bewaard bij de geteste firmware- en platformversies. Met dat bewijs kan een later geschil worden opgelost door de gegevens te lezen in plaats van te discussiëren. Het maakt een regressietest na een nieuwe release aan beide zijden ook zinvol.

Voor inkoop

De bewering van een leverancier dat OCPP wordt ondersteund, is een startpunt. Door vóór de gunning tegen uw beoogde platform te testen, verandert die bewering in iets waarop u kunt vertrouwen. Het is hetzelfde werk, maar dan eerder in het commerciële proces en vóór de uitrol.

Wat de test niet doet

Een interoperabiliteitstest is geen certificering en verklaart namens geen enkele instantie dat een product conform is. De test rapporteert het waargenomen gedrag tussen twee concrete implementaties in specifieke versies. Dat is een beperktere, maar voor de operatie nuttigere uitspraak.

Waar interoperabiliteit werkelijk om draait

Een conformiteitstest vraagt of een implementatie de specificatie volgt. Een interoperabiliteitstest vraagt of twee concrete systemen samenwerken. Slagen voor de eerste test zegt weinig over de tweede vraag, terwijl kopers vaak aannemen dat beide hetzelfde zijn.

We hebben een als OCPP-conform verkocht laadstation niet zien werken met het platform waarvoor de eigenaar al had gekozen. Het probleem was geen ontbrekende conformiteit. Conformiteit en interoperabiliteit zijn verschillende vragen, en slechts één daarvan was gesteld.

• Welk platform en welke release, niet alleen welke OCPP-versie
• De berichtenset waarvan uw operatie werkelijk afhankelijk is, inclusief berichten die pas belangrijk worden wanneer iets misgaat
• Gedrag na opnieuw verbinden, bij een onbereikbaar backend en bij een gedeeltelijk voltooide transactie, omdat implementaties daar uiteenlopen
• Firmware-updates over the air, van begin tot eind getest, omdat u juist dat mechanisme nodig heeft wanneer later iets anders fout blijkt te zijn

Hoe we hierin met u samenwerken

Testresultaten zijn alleen bruikbaar als de mensen die ermee aan de slag moeten begrijpen wat wel en niet is getest. Daarom spreken we het testplan vooraf met uw team af en vermelden de bevindingen ook wat buiten de dekking viel.

We zeggen het ook wanneer testen niet de juiste besteding is. Als het antwoord al uit de architectuur blijkt, bevestigt een testprogramma dat alleen tegen onnodig hoge kosten.

De twee situaties waarvoor dit bedoeld is

Vrijwel iedere opdracht op dit gebied valt in een van twee situaties. Beide draaien om een specifieke combinatie van systemen en niet om conformiteit in algemene zin.

1. 1

   Een laadstation van een andere leverancier tegen uw platform testen

   U overweegt hardware van een leverancier waarmee u nog niet werkt, of u heeft die al aangeschaft. De vraag is of deze werkelijk samenwerkt met uw managementsysteem, in de release die u gebruikt en voor de functies waarvan uw operatie afhankelijk is.

2. 2

   Van platform veranderen en uw bestaande vloot opnieuw testen

   U stapt over naar een ander CSMS. Ieder laadstation in de vloot krijgt nu te maken met een backend waarmee het nog nooit heeft gesproken. Uit de datasheets valt niet te voorspellen welke apparaten zich afwijkend zullen gedragen. Testen vóór de migratie is veel goedkoper dan dit tijdens de overstap ontdekken.

Beide situaties worden op dezelfde manier beantwoord: tegen het genoemde platform en de specifieke release, met de voor u relevante berichtenset en inclusief de foutpaden.

De gezamenlijke werkwijze

Voor de eerste test stellen we samen de checklist op. Dit is het centrale werkdocument van de volledige opdracht.

1. 1

   Wij stellen een eerste versie op voor uw operatie

   We kijken naar wat uw vloot en platform doen en welk afwijkend gedrag werkelijk schade veroorzaakt. Een algemene conformiteitslijst test functies waarvan niemand afhankelijk is en mist juist de belangrijke gevallen.

2. 2

   U vult de lijst aan

   Uw engineers kennen de situaties die eerder problemen hebben veroorzaakt. Die nemen we op en het zijn vaak de waardevolste punten van de checklist.

3. 3

   Wij voeren hem iedere keer volledig uit

   Dezelfde checklist wordt gebruikt voor ieder apparaat en ieder platform binnen de scope. Daardoor zijn resultaten vergelijkbaar en niet slechts anekdotisch.

4. 4

   U houdt de checklist

   Na afloop is de checklist van u. Hij wordt de acceptatietest voor de volgende leverancier en de volgende migratie, en is daarmee waardevoller dan één afzonderlijk testrapport.