Kjøretøyprotokoll vs Backend-protokoll: To separate stabler

En lader sitter mellom to samtaler som ikke møtes. På den ene siden snakker det med kjøretøyet om hvor mye strøm som skal tas og hvem som betaler. På den andre siden snakker den med en backend om økter, målere og fjernkommandoer. De to bruker ulike protokoller, ulike datamodeller og ulike sertifiseringsregimer.

Kjøpere blander dem stadig sammen, og sammenblandingen fører til noen av de dyreste misforståelsene i anskaffelser: en spesifikasjon som krever en moderne backend-protokoll i troen på at den leverer plug and charge, eller en biloppgradering som forventes å løse et faktureringsproblem. Å skille lagene gjør hvert krav sjekkbart for seg selv.

to stabler, to jobber

Den nedre stakken går over ladekabelen. Den håndterer den fysiske tilkoblingen, sikkerhetskontroller før strøm tilføres, forhandling av ladeparametere, og — i sine senere versjoner — identiteten til kjøretøyet og sertifikatutvekslingen som tillater automatisk autorisasjon.

Den øverste stakken går over en nettverksforbindelse, vanligvis mobildata eller et steds-LAN. Den bærer det operatøren trenger: start- og stoppkommandoer, transaksjonsposter, målerverdier, diagnostikk, fastvarehåndtering og konfigurasjon. Den har ingen direkte utsikt til kjøretøyet. Alt den vet om en økt, lærte den fra laderen.

Den asymmetrien er nøkkelen til hele motivet. Laderen er en oversetter med egne meninger, ikke et gjennomsiktig rør. Det backend registrerer, er det laderen valgte å rapportere, i det formatet den øvre protokollen definerer.

Mellom kjøretøy og lader

Den eldre løsningen er enkel og fortsatt universell som en reserveplan. Et pulsbreddemodulert signal på kontrollpiloten overfører maksimal strøm, kjøretøyet svarer ved å endre et spenningsnivå, og laderen lukker kontaktoren når sekvensen tillater det. Det finnes ingen datakanal i moderne forstand og ingen identitetsutveksling. Autorisasjon skjer utenfor protokollen, gjennom en kortleser, en app eller en manuell utløsning.

Høynivåprotokollene legger til en datakanal. ISO 15118 og forgjengeren DIN 70121 fører en strukturert samtale over kraftlinjekommunikasjon: kjøretøyet identifiserer seg, de to sidene utveksler kapasiteter, kjøretøyet sier hva det ønsker, og laderen rapporterer hva det kan levere. Utvekslingen fortsetter gjennom hele økten, og derfor kan laderen se kjøretøyets forespørsel i stedet for bare den resulterende strømmen.

De senere utgavene av ISO 15118 utvider dette til sertifikatbasert identitet, som er det som gjør automatisk autorisasjon mulig, og til toveis energioverføring. Begge utvidelsene krever maskinvare og programvare som en lader kun bygget til den tidligere utgaven ikke har.

Dette laget er der kjøretøyets egenskaper kommer inn i systemet. Det er også der en laders egen dokumentasjon vanligvis sier to separate ting: hvilken høynivåprotokoll den kommuniserer med kjøretøyet, og hvilken backend-protokoll den sier oppover.

Mellom Charger og Backend

Den dominerende protokollen her er OCPP, en åpen standard vedlikeholdt av en bransjeorganisasjon og implementert uavhengig av ladeprodusenter og backend-plattformer. Den definerer meldinger for autorisasjon, oppstart og stopp av transaksjoner, målerverdier, statusvarsler, fjernkommandoer, fastvareoppdateringer og konfigurasjon.

Senere versjoner av OCPP legger til enhetsadministrasjon, forbedrede smarte ladeprofiler og en mer strukturert tilnærming til sammensatte tidsplaner. Den praktiske forskjellen for en operatør er hvor mye kontroll backend har over når og hvor raskt hver kontakt lades, og hvor mye av dette som kan endres uten et besøk på stedet.

Det OCPP ikke gjør, er å kommunisere med kjøretøyet. En backend som støtter den nyeste versjonen lærer fortsatt om kjøretøyet på nytt. Hvis laderen ikke rapporterer en verdi, kan ikke backend vise den, og ingen mengde plattform-sofistikasjon henter den tilbake.

Samsvar legger til et ekstra lag av forvirring. OCPP-samsvar er sertifisert for en lader mot en definert versjon, og sertifiseringen tilhører både det produktet og den versjonen. Den sier ingenting om kjøretøysidens protokoll, og den sier ingenting om hvor godt en bestemt backend implementerer samme versjon. To konforme produkter kan fortsatt ikke samarbeide på de valgfrie delene av spesifikasjonen, og derfor eksisterer integrasjonstesting som en separat aktivitet.

Hvorfor plugg og lading trenger begge sider

Automatisk autorisasjon, vanligvis beskrevet som plug and charge, er en kjede snarere enn en funksjon. Kjøretøyet presenterer et kontraktsertifikat over høynivåprotokollen. Laderen validerer den mot en sertifikatkjede den stoler på, og autoriserer enten lokalt eller videresender identiteten oppover for en avgjørelse. Backend bekrefter at kontrakten er gyldig og kan faktureres.

Hver lenke må være til stede. Et kjøretøy uten kontraktsbevis kan ikke fremvise et. En lader uten høynivåprotokoll og tillitsbutikken kan ikke lese den. En backend uten tilsvarende sertifikathåndtering kan ikke løse det. Når en lenke mangler, faller økten tilbake til et kort, en app eller en QR-kode — noe som er akkurat det sjåfører opplever på nettverk som reklamerer for automatisk lading og kun leverer den for enkelte bil- og operatørkombinasjoner.

Dette er også grunnen til at funksjonen er ujevnt tilgjengelig i praksis. Den avhenger av skjæringspunktet mellom tre uavhengig oppdaterte systemer, og skjæringspunktet er mindre enn noen av dem.

Oppgradering av den ene oppgraderer ikke den andre

Fire vanlige antakelser feiler av samme grunn.

At en nyere backend-protokoll gir automatisk autorisasjon. Det gjør den ikke, fordi autorisasjonen sendes på den nedre stakken. En lader kan bruke den nyeste backend-versjonen og fortsatt kreve et kort.

At et kjøretøy som støtter automatisk lading fungerer på hvilket som helst nettverk. Det fungerer der laderen og backend er konfigurert for det, og operatøren har et roaming- eller kontraktsforhold med kjøretøyets leverandør.

At en firmwareoppdatering til laderen legger til en kjøretøysidefunksjon. Laderen versjon av samtalen kan oppdateres. Kjøretøyet kan ikke, fra laderen.

Og den ene sertifiseringen dekker begge. Sertifiseringer utstedes per produkt, per protokoll og per versjon, og et sertifikat som navngir ett lag sier ingenting om det andre.

En godt spesifisert lader oppgir de to lagene separat, og produkter i dette sortimentet lister vanligvis en backend-protokollversjon sammen med kjøretøyprotokollene de støtter. 120 og 180 kW stasjonsspesifikasjon gjør dette, og separasjonen er det som gjør de to kravene individuelt testbare.

Hvordan skrive dette inn i et krav

Et krav som ikke kan testes, er ikke et krav. Fire linjer gjør den testbar.

Oppgi hvilken kjøretøyside-protokoll og versjon laderen må støtte, og om automatisk autorisasjon kreves på det grensesnittet. Oppgi backend-protokollen og versjonen, og om samsvar må sertifiseres eller bare erklæres. Oppgi fallback-atferden når en av forhandlingene mislykkes, fordi et nettsted som stille går over i en uautentisert modus er et inntektsproblem. Og oppgi hvilket bevis som aksepteres: et sertifikatnummer, en testrapport eller en felles test med plattformen operatøren har til hensikt å bruke.

Den siste av disse er den som fanger de fleste prosjekter. Konformitetstesting beviser at et produkt oppfyller en spesifikasjon. Integrasjonstesting beviser at to produkter fungerer sammen. Innkjøpsdokumenter ber ofte om det første og krever det andre, og gapet blir først synlig etter at maskinvaren er levert.

Forholdet mellom disse protokollene og laststyring er nært nok til å skape forvirring: en smart ladeprofil levert over backend-protokollen er en instruksjon til laderen, som deretter må følge den innenfor det kjøretøyet aksepterer. Denne interaksjonen behandles i notatet på last management, som beskriver hvor instruksjonen slutter og kjøretøyets egne grenser begynner.

For de fleste operatører er den praktiske konsekvensen en sjekkliste snarere enn en redesign. Skriv de to protokollkravene på separate linjer, navngi versjonen for hver, spør hva som skjer når forhandlingene mislykkes, og test kombinasjonen før nettstedet åpner i stedet for etter den første klagen.