Checklista för acceptanstestning av programvara för laddning av elbilar

1. Definiera testomfattningen innan laddare ansluts

Börja med affärsprocessen snarare än funktionslistan. En offentlig laddplats behöver en annan acceptansplan än en privat depå. Skriv ner vem som kan ladda, hur de identifierar sig, vem som betalar, vilken tariff som gäller och vem som svarar när något misslyckas. Gör varje krav observerbart.

Skapa en utrustningsmatris som innehåller tillverkare, modell, firmware, kontaktidentifierare, kommunikationsmetod och protokollversion som stöds. Två laddare från samma märke kan bete sig olika efter en firmwareändring. Behandla en väsentligt annorlunda konfiguration som ett separat testfall istället för att anta att en lyckad session täcker hela nätverket.

Tilldela en ägare till varje test. Operatören bör godkänna affärsresultatet, medan programvaruleverantören, laddartillverkaren, betalningsintegratören och installatören tillhandahåller bevis för sina respektive delar. Registrera beroenden tidigt så att ett saknat handelskonto inte ser ut som en plattformsdefekt.

2. Verifiera laddarens integration utöver online-indikatorn

De första kontrollerna bör omfatta identitet och status. Bekräfta att rätt laddare, plats och kontakt visas i plattformen. Jämför den fysiska etiketten med instrumentpanelen och förargränssnittet. En förare som skannar kontakt två får inte av misstag starta kontakt ett.

Testa startregistrering, statusändringar, mätarrapportering och slutförande av transaktioner. Testa sedan kommandona som ingår i ditt kontrakt, såsom fjärrstart, fjärrstopp och hämtning av diagnostik. Ett kommando markerat med "accepterat" är bara ett bevis; verifiera att det avsedda fysiska resultatet faktiskt inträffade.

De Open Charge Alliance förklarar att OCPP 1.6 och 2.0.1 inte är kompatiblaEn plattform som fungerar båda behöver lämpliga implementeringar och validering på laddningsnivå. Fråga vilka funktioner som testades på just din utrustning snarare än att acceptera ett brett kompatibilitetsutlåtande.

För bakgrundsinformation om integrationsomfattningen, granska TRENDPOWERs publicerade riktlinjer för OCPP-supportSpara den överenskomna modellen och firmware-matrisen bifogad till godkännandeprotokollet.

3. Testa åtkomst och hela förarresan

Gå igenom processen som en ny förare, inte som en administratör som redan vet var varje knapp finns. Hitta webbplatsen, identifiera kontakten, läs priset, autentisera, börja debitera och få den slutliga posten. Kontrollera mobilupplevelsen på de enheter och webbläsare som din målgrupp faktiskt använder.

Inkludera giltiga och ogiltiga inloggningsuppgifter, utgången åtkomst, en anslutning som redan används och upprepade startförfrågningar. Verifiera att obehöriga förare får en användbar förklaring utan att kontoinformation exponeras. Där RFID, ett webbgränssnitt eller en varumärkesapp ingår, testa varje rutt separat.

För delade webbplatser, testa behörigheter från båda sidor. Bekräfta att en godkänd besökare kan debitera och att en besökare med utgången avgift inte kan det. Bekräfta sedan att ändrad åtkomst inte retroaktivt ändrar den historiska registreringen av en tidigare session.

4. Beräkna om fakturerings- och betalningsresultat separat

Välj en liten grupp sessioner med kända indata. Använd först en enkel energitariff och testa sedan eventuella överenskomna anslutningsavgifter, tidskomponenter, rabatter eller vilolägesavgifter. Beräkna den förväntade avgiften separat och jämför den med plattformen, kvittot och betalningsleverantörens post.

Inkludera randvillkor: en tariff som ändras vid midnatt, en session som sträcker sig över två prissättningsperioder, en nollenergisession och avrundning till den minsta valutaenhet som stöds. Registrera tillämplig tidszon och policy för sessioner som redan pågår när en tariff ändras.

Betalningstester bör inkludera lyckad auktorisering, misslyckad auktorisering, misslyckad debiteringsstart och försenad leverantörsavisering. Kontrollera att upprepade återuppringningar inte leder till upprepade debiteringar. För en bredare bild av den kommersiella uppsättningen, använd Översikt över betalningslösningen för laddning av elbilar tillsammans med din leverantörs egna integrationskrav.

5. Validera lastkontroller under realistiska förhållanden

Om lasthantering ingår, testa det med platsingenjören och överenskommen instrumentering. Definiera kontrollgränsen tydligt: en laddningsgrupp, en matare eller hela byggnaden. En instrumentpanelssumma baserad enbart på laddningsdata kan inte bevisa att hela byggnaden håller sig inom sin gräns.

Använd ett kontrollerat test för att lägga till laddningsbehov och ändra relevant byggnadsbelastning. Jämför den begärda gränsen, laddarens respons och det uppmätta resultatet. Ta hänsyn till det dokumenterade responsintervallet och mättoleransen; uppfinn inte ett universellt tröskelvärde som utrustningen inte kan uppfylla.

Testa den överenskomna reservlösningen när platsens mätare, lokala styrenhet eller molnanslutning blir otillgänglig. Registrera vem som får larmet och hur driften återupptas. Programvaruschemaläggning stöder den konstruerade styrstrategin; den ersätter inte elektriskt skydd eller en godkänd platsdesign.

6. Kör fel- och återställningsscenarier

Ett produktionsnätverk behöver förutsägbart beteende när komponenter försvinner. Avbryt laddarens internetanslutning, starta om applikationen där det är tillåtet och simulera en missad avisering i en kontrollerad miljö. Kontrollera förarens vy, operatörslarm och eventuell avstämning.

Offlinebeteende beror på laddarens kapacitet och konfiguration. Anta inte att en session kan starta offline bara för att en befintlig session har fortsatt. Separera dessa fall och ange exakt vilka åtkomstmetoder och lokala kontroller som förväntas fungera.

Efter återanslutning, kontrollera tidslinjen för luckor, dubbletter och felaktiga tidsstämplar. Läs den befintliga Guide för offlineladdning av elbilar när man definierar dessa fall. Inkludera bevis på återställning i överlämningen, inte bara en skärmdump av laddaren när den återgår till online.

7. Kontrollera behörigheter, exporter och operativ överlämning

Logga in som webbplatsvärd, supportagent, ekonomianvändare och administratör. Testa både tillåtna och blockerade åtgärder, inklusive tariffändringar, återbetalningar, exporter och fjärrkommandon där dessa funktioner finns. En roll bör ha tillräckligt med åtkomst för att utföra sitt jobb utan att bli en genväg till alla webbplatsers data.

Exportera testsessionerna och jämför totalerna med instrumentpanelen. Kontrollera kopplingsidentitet, tidsstämplar, energienheter, valuta, skattefält där så är tillämpligt och ekonomisk status. Fråga hur korrigeringar visas och om en revisionslogg identifierar den ansvariga personen eller det ansvariga systemet.

Slutligen, låt de personer som ska driva nätverket utföra rutinuppgifterna. De bör veta hur man undersöker en misslyckad start, kontaktar rätt leverantör, hittar en betalningsreferens och förklarar en pågående betalning för en förare. En tekniskt komplett plattform kan fortfarande misslyckas med sin överlämning om dessa steg förblir oklara.

8. Kom överens om lanseringskriterier och etappvis utrullning

Använd skriftliga släppkriterier som överenskommits före testning. Till exempel kan ditt projekt kräva att alla kritiska arbetsflöden godkänns, att alla blockerande fel åtgärdas och att alla accepterade mindre problem har en ägare och ett måldatum. Dessa är projektbeslut, inte ett branschövergripande certifieringssystem.

Börja med ett litet pilotprojekt som representerar det bredare nätverket. Inkludera de laddtyper, åtkomstmetoder och betalningsvägar som medför störst operativ risk. Utöka endast efter att ha granskat aktuella register och bekräftat att supportteamen kan hantera de observerade problemen.

Acceptanspaketet bör innehålla utrustningsmatrisen, testfall, resultat, fellogg, konfigurationsbaslinje, driftskontakter och återställningsprocedur. Detta blir en användbar referens när en senare firmwareuppdatering eller tariffändring introducerar oväntat beteende.

Vanliga frågor

Räcker ett OCPP-anslutningstest för godkännande?

Nej. Det bekräftar bara en del av systemet. Du behöver fortfarande verifiera de överenskomna förarresorna, tarifferna, betalningsresultaten, behörigheterna, rapporterna och återkravsprocedurerna i den faktiska projektkonfigurationen.

Borde alla laddare genomgå samma testning?

Varje installerad enhet behöver överenskomna driftsättningskontroller. Djupet av upprepade programvarutestningar kan följa en riskbaserad urvalsplan, men olika modeller, firmwareversioner och ovanliga platskonfigurationer behöver uttryckligen beaktas.

Vem godkänner programvaran?

Operatören bör utse en ansvarig godkännare. Leverantörerna tillhandahåller bevis för sin egen omfattning, medan godkännande av el och säkerhet förblir hos lämpligt kvalificerade parter. Gör dessa ansvarsområden till en del av projektavtalet.