Checklist voor acceptatietesten van software voor het opladen van elektrische voertuigen

1. Bepaal de testomvang voordat u de laders aansluit.

Begin met het bedrijfsproces in plaats van de functielijst. Een openbaar laadstation vereist een ander acceptatieplan dan een particulier depot. Beschrijf wie er mag laden, hoe ze zich identificeren, wie betaalt, welk tarief van toepassing is en wie verantwoordelijk is als er iets misgaat. Zorg ervoor dat elke vereiste observeerbaar is.

Maak een apparatuurmatrix met daarin de fabrikant, het model, de firmware, de connector-ID's, de communicatiemethode en de ondersteunde protocolversie. Twee laders van hetzelfde merk kunnen zich anders gedragen na een firmware-update. Beschouw een wezenlijk andere configuratie als een aparte testcase in plaats van aan te nemen dat één succesvolle sessie het hele netwerk dekt.

Wijs aan elke test een verantwoordelijke toe. De operator moet het bedrijfsresultaat goedkeuren, terwijl de softwareleverancier, de fabrikant van de oplader, de betalingsintegrator en de installateur bewijsmateriaal leveren voor hun respectievelijke onderdelen. Leg afhankelijkheden vroegtijdig vast, zodat een ontbrekend merchant account niet wordt aangezien voor een platformfout.

2. Controleer de integratie van de lader, naast de online indicator.

De eerste controles moeten betrekking hebben op de identiteit en status. Controleer of de juiste lader, locatie en connector in het platform worden weergegeven. Vergelijk het fysieke label met het dashboard en de bestuurdersinterface. Een bestuurder die connector twee scant, mag niet per ongeluk connector één starten.

Test de opstartregistratie, statuswijzigingen, meterstanden en de voltooiing van transacties. Test vervolgens de commando's die in uw contract zijn opgenomen, zoals starten op afstand, stoppen op afstand en het opvragen van diagnostische gegevens. Een commando dat als "geaccepteerd" is gemarkeerd, is slechts één bewijs; controleer of het beoogde fysieke resultaat daadwerkelijk is bereikt.

De Open Charge Alliance legt uit dat OCPP 1.6 en 2.0.1 niet compatibel zijn.Een platform dat beide functies biedt, vereist passende implementaties en validatie op laderniveau. Vraag welke functies op uw specifieke apparatuur zijn getest in plaats van een algemene compatibiliteitsverklaring te accepteren.

Voor achtergrondinformatie over de reikwijdte van de integratie, zie De door TRENDPOWER gepubliceerde OCPP-ondersteuningsrichtlijnen. Bewaar de overeengekomen model- en firmwarematrix bij het acceptatieverslag.

3. Test de toegang en de volledige rijroute

Doorloop het proces als een nieuwe chauffeur, niet als een beheerder die al weet waar elke knop zit. Zoek de locatie, identificeer de connector, lees de prijs, authenticeer, start de facturering en ontvang de eindafrekening. Controleer de mobiele ervaring op de apparaten en browsers die uw doelgroep daadwerkelijk gebruikt.

Neem zowel geldige als ongeldige inloggegevens, verlopen toegang, een reeds in gebruik zijnde connector en herhaalde startverzoeken mee. Controleer of onbevoegde chauffeurs een nuttige uitleg ontvangen zonder dat accountgegevens worden prijsgegeven. Test elke route afzonderlijk wanneer RFID, een webinterface of een merkgebonden app is inbegrepen.

Test bij gedeelde sites de machtigingen aan beide zijden. Controleer of een geautoriseerde bezoeker kosten in rekening kan brengen en of een bezoeker wiens account is verlopen dat niet kan. Controleer vervolgens of het wijzigen van de toegang geen terugwerkende kracht heeft op de historische gegevens van een eerdere sessie.

4. Herbereken de facturerings- en betalingsresultaten onafhankelijk van elkaar.

Kies een kleine groep sessies met bekende input. Gebruik eerst een eenvoudig tarief dat alleen energie omvat, en test vervolgens de overeengekomen aansluitkosten, tijdcomponent, korting of inactiviteitskosten. Bereken de verwachte kosten afzonderlijk en vergelijk deze met de gegevens van het platform, de bon en de betalingsprovider.

Voeg randvoorwaarden toe: een tariefwijziging om middernacht, een sessie die twee prijsperioden omvat, een sessie met nul energieverbruik en afronding naar de kleinste ondersteunde valuta-eenheid. Noteer de toepasselijke tijdzone en het beleid voor sessies die al bezig zijn wanneer een tarief wijzigt.

Betalingstests moeten een succesvolle autorisatie, een mislukte autorisatie, een mislukte start van de betaling en een vertraagde melding aan de provider omvatten. Controleer of herhaalde terugbelverzoeken niet leiden tot herhaalde betalingen. Voor een breder overzicht van de commerciële configuratie kunt u de volgende informatie raadplegen: Overzicht van betaaloplossingen voor het opladen van elektrische voertuigen in combinatie met de integratievereisten van uw provider.

5. Valideer de lastregeling onder realistische omstandigheden.

Als loadmanagement tot de mogelijkheden behoort, test dit dan met de projectleider en de overeengekomen meetinstrumenten. Definieer de controlegrens duidelijk: een groep laders, een voedingslijn of het hele gebouw. Een dashboardtotaal gebaseerd op alleen ladergegevens kan niet aantonen dat het hele gebouw binnen de limiet blijft.

Gebruik een gecontroleerde test om de laadvraag te verhogen en de relevante gebouwbelasting te wijzigen. Vergelijk de gevraagde limiet, de reactie van de lader en het gemeten resultaat. Houd rekening met het gedocumenteerde reactie-interval en de meettolerantie; verzin geen universele drempelwaarde waaraan de apparatuur niet kan voldoen.

Test de overeengekomen terugvalprocedure wanneer de meter op locatie, de lokale controller of de cloudverbinding niet beschikbaar is. Registreer wie de melding ontvangt en hoe de werkzaamheden worden hervat. Softwareplanning ondersteunt de ontworpen besturingsstrategie; het vervangt geen elektrische beveiliging of een goedgekeurd locatieontwerp.

6. Voer fout- en herstelscenario's uit.

Een productienetwerk moet voorspelbaar gedrag vertonen wanneer componenten uitvallen. Verbreek de internetverbinding van de lader, herstart de applicatie indien toegestaan en simuleer een gemiste melding in een gecontroleerde omgeving. Controleer de weergave voor de bestuurder, de melding aan de operator en de uiteindelijke afstemming.

Het offline gedrag is afhankelijk van de mogelijkheden en configuratie van de lader. Ga er niet van uit dat een sessie offline kan starten simpelweg omdat een bestaande sessie is voortgezet. Maak onderscheid tussen deze gevallen en geef precies aan welke toegangsmethoden en lokale instellingen naar verwachting zullen werken.

Controleer na de herverbinding de tijdlijn op hiaten, duplicaten en onjuiste tijdstempels. Lees de bestaande gegevens. Handleiding voor het offline opladen van elektrische voertuigen Bij het definiëren van deze gevallen, voeg bewijs van herstel toe aan de overdracht, niet alleen een screenshot van de lader die weer online is.

7. Controleer de vergunningen, exportmogelijkheden en operationele overdracht.

Log in als sitebeheerder, supportmedewerker, financieel gebruiker en beheerder. Test zowel toegestane als geblokkeerde acties, waaronder tariefwijzigingen, terugbetalingen, exporten en opdrachten op afstand, indien deze functies beschikbaar zijn. Een rol moet voldoende toegang hebben om zijn werk te kunnen doen, zonder een sluiproute te worden naar alle gegevens op de site.

Exporteer de testsessies en vergelijk de totalen met het dashboard. Controleer de connectoridentiteit, tijdstempels, energie-eenheden, valuta, belastingvelden (indien van toepassing) en de financiële status. Vraag hoe correcties worden weergegeven en of een auditlogboek de verantwoordelijke persoon of het verantwoordelijke systeem identificeert.

Laat tot slot de mensen die het netwerk gaan beheren de routinetaken uitvoeren. Zij moeten weten hoe ze een mislukte opstart moeten onderzoeken, contact moeten opnemen met de juiste leverancier, een betalingsreferentie moeten vinden en een openstaande betaling aan een chauffeur moeten uitleggen. Zelfs een technisch compleet platform kan mislukken bij de overdracht als deze stappen onduidelijk blijven.

8. Stem de releasecriteria en de gefaseerde uitrol af.

Gebruik schriftelijke vrijgavecriteria die vóór de tests zijn overeengekomen. Uw project kan bijvoorbeeld vereisen dat elke kritieke workflow slaagt, alle blokkerende defecten worden opgelost en dat elk geaccepteerd klein probleem een verantwoordelijke en een streefdatum heeft. Dit zijn projectbeslissingen, geen branchebreed certificeringsschema.

Begin met een kleinschalige pilot die representatief is voor het bredere netwerk. Neem de laadpaaltypes, toegangsmethoden en betalingsprocessen op die het grootste operationele risico met zich meebrengen. Breid pas uit na het analyseren van de live gegevens en na bevestiging dat de supportteams de geconstateerde problemen aankunnen.

Het acceptatiepakket moet de apparatuurmatrix, testgevallen, resultaten, defectenlogboek, configuratiebasislijn, operationele contactgegevens en terugdraaiprocedure bevatten. Dit dient als nuttig naslagwerk wanneer een latere firmware-update of tariefwijziging onverwacht gedrag veroorzaakt.

Veelgestelde vragen

Is een OCPP-verbindingstest voldoende voor acceptatie?

Nee. Het bevestigt slechts een deel van het systeem. U moet de overeengekomen chauffeursritten, tarieven, betalingsresultaten, vergunningen, rapporten en incassoprocedures nog steeds controleren in de daadwerkelijke projectconfiguratie.

Moet elke oplader dezelfde tests ondergaan?

Elke geïnstalleerde unit moet de overeengekomen inbedrijfstellingscontroles ondergaan. De diepte van de herhaalde softwaretests kan een risicogebaseerd steekproefplan volgen, maar verschillende modellen, firmwareversies en ongebruikelijke locatieconfiguraties vereisen expliciete dekking.

Wie keurt de software goed?

De opdrachtgever dient een verantwoordelijke goedkeurder aan te wijzen. Leveranciers leveren bewijs voor hun eigen werkzaamheden, terwijl de elektrische en veiligheidsgoedkeuring bij de daarvoor bevoegde partijen blijft. Neem deze verantwoordelijkheden op in de projectovereenkomst.