Fordonsprotokoll vs Backend-protokoll: Två separata stackar

En laddare sitter mellan två samtal som inte möts. På ena sidan talar det till fordonet om hur mycket ström som ska tas emot och vem som betalar. Å andra sidan pratar den med en backend om sessioner, mätare och fjärrkommandon. De två använder olika protokoll, olika datamodeller och olika certifieringsregimer.

Köpare blandar ihop dem ständigt, och sammanblandningen leder till några av de dyraste missförstånden vid upphandling: en specifikation som kräver ett modernt backend-protokoll i tron att det levererar plug and charge, eller en fordonsuppgradering som förväntas lösa ett faktureringsproblem. Att separera lagren gör varje krav kontrollerbart för sig.

Två stackar, två jobb

Den nedre stacken går över laddningskabeln. Den hanterar den fysiska anslutningen, säkerhetskontroller innan ström appliceras, förhandling av laddningsparametrar och — i senare versioner — fordonets identitet och certifikatutbytet som möjliggör automatisk auktorisation.

Den övre stacken körs över en nätverksanslutning, vanligtvis mobildata eller ett plats-LAN. Den bär det operatören behöver: start- och stoppkommandon, transaktionsposter, mätvärden, diagnostik, firmwarehantering och konfiguration. Den har ingen direkt sikt mot fordonet. Allt den vet om en session har den lärt sig från laddaren.

Den asymmetrin är nyckeln till hela motivet. Laddaren är en översättare med egna åsikter, inte ett transparent rör. Vad backend registrerar är vad laddaren valde att rapportera, i det format som det övre protokollet definierar.

Mellan fordon och laddare

Den äldre arrangemanget är enkelt och fortfarande universellt som reservplan. En pulsbreddmodulerad signal på styrpiloten överför en maximal ström, fordonet svarar genom att ändra en spänningsnivå, och laddaren stänger sin kontaktor när sekvensen tillåter. Det finns ingen datakanal i modern mening och inget identitetsutbyte. Auktorisering sker utanför protokollet, via en kortläsare, en app eller en manuell frigivning.

Högnivåprotokollen lägger till en datakanal. ISO 15118 och dess föregångare DIN 70121 för en strukturerad kommunikation via kraftledning: fordonet identifierar sig, de två sidorna utbyter förfäenheter, fordonet anger vad det vill och laddaren rapporterar vad den kan tillhandahålla. Utbytet fortsätter under hela sessionen, vilket är anledningen till att laddaren kan se fordonets begäran istället för bara den resulterande strömmen.

De senare utgåvorna av ISO 15118 utvidgar detta till certifikatbaserad identitet, vilket är det som gör automatisk auktorisation möjlig, samt till tvåvägs energiöverföring. Båda tilläggen kräver hårdvara och mjukvara som en laddare som endast byggts till den tidigare versionen inte har.

Detta lager är där fordonets egenskaper kommer in i systemet. Det är också där en laddares egen dokumentation vanligtvis anger två separata saker: vilket högnivåprotokoll den talar med fordonet, och vilket backend-protokoll den talar uppåt.

Mellan laddare och backend

Det dominerande protokollet här är OCPP, en öppen standard som underhålls av en branschorganisation och implementeras oberoende av laddartillverkare och backendplattformar. Den definierar meddelanden för auktorisation, transaktionsstart och -stopp, mätarvärden, statusnotiser, fjärrkommandon, firmwareuppdateringar och konfiguration.

Senare versioner av OCPP lägger till enhetshantering, förbättrade smarta laddningsprofiler och ett mer strukturerat tillvägagångssätt för sammansatta scheman. Den praktiska skillnaden för en operatör är hur mycket kontroll backend har över när och hur snabbt varje kontakt laddas, och hur mycket av det som kan ändras utan ett platsbesök.

Det OCPP inte gör är att prata med fordonet. En backend som stöder den senaste versionen lär sig fortfarande om fordonet på andra hand. Om laddaren inte rapporterar ett värde kan backend inte visa det, och ingen mängd plattformssofistikering återställer det.

Compliance lägger till ytterligare ett lager av förvirring. OCPP-konformitet är certifierad för en laddare mot en definierad version, och certifieringen tillhör både den produkten och den versionen. Det står inget om fordonssidans protokoll, och det står inget om hur väl en viss backend implementerar samma version. Två konforma produkter kan fortfarande misslyckas med att samverka på de valfria delarna av specifikationen, vilket är anledningen till att integrationstestning existerar som en separat aktivitet.

Varför Plug and Charge behöver båda sidor

Automatisk auktorisering, vanligtvis beskriven som plug and charge, är en kedja snarare än en funktion. Fordonet presenterar ett kontraktsintyg över det övergripande protokollet. Laddaren validerar den mot en certifikatkedja den litar på, och godkänner antingen lokalt eller vidarebefordrar identiteten uppåt för ett beslut. Backend bekräftar att kontraktet är giltigt och kan faktureras.

Varje länk måste finnas med. Ett fordon utan kontraktsintyg kan inte visa upp ett. En laddare utan högnivåprotokollet och förtroendelagringen kan inte läsa det. En backend utan motsvarande certifikathantering kan inte lösa det. När någon länk saknas återgår sessionen till ett kort, en app eller en QR-kod – vilket är precis vad förare upplever på nätverk som annonserar automatisk laddning och bara levererar den för vissa fordons- och förarkombinationer.

Det är också därför funktionen är ojämnt tillgänglig i praktiken. Det beror på skärningspunkten mellan tre oberoende uppdaterade system, och snittet är mindre än något av dem.

Att uppgradera det ena uppgraderar inte det andra

Fyra vanliga antaganden misslyckas av samma anledning.

Att ett nyare backend-protokoll ger automatisk auktorisering. Det gör den inte, eftersom auktorisationen färdas på den nedre stacken. En laddare kan kommunicera den senaste backend-versionen och ändå kräva ett kort.

Att ett fordon som stöder automatisk laddning fungerar på vilket nätverk som helst. Det fungerar där laddaren och backend är konfigurerade för det och operatören har ett roaming- eller kontraktsförhållande med fordonets leverantör.

Att en firmwareuppdatering av laddaren lägger till en fordonssida. Laddarens sida av samtalet kan uppdateras. Fordonet kan inte, från laddaren.

Och den certifieringen täcker båda. Certifieringar utfärdas per produkt, per protokoll och per version, och ett certifikat som namnger ett lager säger inget om det andra.

En välspecificerad laddare anger de två lagren separat, och produkter i detta intervall listar vanligtvis en backend-protokollversion tillsammans med de fordonsbaserade protokoll de stödjer. Stilen 120 och 180 kW stationsspecifikationen gör detta, och separationen är det som gör de två kraven individuellt testbara.

Hur man skriver detta i ett krav

Ett krav som inte kan testas är inget krav. Fyra linjer gör det testbart.

Ange vilket fordonsbaserat protokoll och version laddaren måste stödja, och om automatisk auktorisation krävs på det gränssnittet. Ange backend-protokoll och version, samt om konformitet måste certifieras eller bara deklareras. Ange reservbeteendet när någon av förhandlingarna misslyckas, eftersom en sajt som tyst går över till ett oautentiserat läge är ett intäktsproblem. Och ange vilka bevis som accepteras: ett certifikatnummer, en testrapport eller ett gemensamt test med plattformen som operatören avser att använda.

Det sista av dessa är det som fångar de flesta projekt. Konformitetstestning bevisar att en produkt uppfyller en specifikation. Integrationstester bevisar att två produkter fungerar tillsammans. Upphandlingsdokument efterfrågar ofta det första och kräver det andra, och luckan blir först synlig efter att hårdvaran har levererats.

Relationen mellan dessa protokoll och belastningshanteringen är tillräckligt nära för att skapa sin egen förvirring: en smart laddningsprofil som levereras över backend-protokollet är en instruktion till laddaren, som sedan måste följa den inom vad fordonet accepterar. Den interaktionen behandlas i anteckningen om last management, som beskriver var instruktionen slutar och fordonets egna gränser börjar.

För de flesta operatörer är den praktiska konsekvensen en checklista snarare än en omdesign. Skriv de två protokollkraven på separata rader, namnge versionen för varje, fråga vad som händer när förhandlingen misslyckas, och testa kombinationen innan sidan öppnar istället för efter det första klagomålet.