Protokol vozila proti backend protokolu: dva ločena sklada

Polnilec stoji med dvema pogovoroma, ki se ne srečata. Na eni strani se pogovarja z vozilom o tem, koliko toka naj vzame in kdo plačuje. Po drugi strani pa komunicira z ozadjem o sejah, merilnikih in oddaljenih ukazih. Oba uporabljata različne protokole, različne podatkovne modele in različne režime certificiranja.

Kupci jih nenehno zamenjujejo, kar povzroča nekatere najdražje nesporazume pri nabavi: specifikacijo, ki zahteva sodoben protokol v ozadju, saj verjamemo, da omogoča plug and charge, ali nadgradnjo vozila, ki naj bi odpravila težavo z obračunavanjem. Ločevanje plasti omogoča, da je vsaka zahteva preverljiva samostojno.

Dva sklada, dve nalogi

Spodnji sklad poteka čez polnilni kabel. Upravlja fizično povezavo, varnostne preglede pred priključitvijo elektrike, pogajanja o parametrih polnjenja in — v kasnejših različicah — identiteto vozila ter izmenjavo certifikatov, ki omogoča samodejno avtorizacijo.

Zgornji sklad poteka preko omrežne povezave, običajno mobilnih podatkov ali lokalnega omrežja. Vsebuje vse, kar operater potrebuje: ukaze za zagon in ustavitev, zapise transakcij, vrednosti števca, diagnostiko, upravljanje in konfiguracijo vdelane programske opreme. Nima neposrednega pogleda na vozilo. Vse, kar ve o seansi, se je naučil od polnilca.

Ta asimetrija je ključ do celotne teme. Polnilec je prevajalnik s svojimi mnenji, ne prozorna cev. Kar zabeleži backend, je tisto, kar je polnilec izbral za poročanje, v obliki, ki jo določa zgornji protokol.

Med vozilom in polnilcem

Starejša ureditev je preprosta in še vedno univerzalna kot rezerva. Signal z modulacijo širine impulza na krmilnem pilotu prenaša največji tok, vozilo se odzove s spremembo napetostne ravni, polnilec pa zapre kontaktor, kadar zaporedje to dopušča. Ni podatkovnega kanala v sodobnem pomenu in ni izmenjave identitete. Avtorizacija poteka zunaj protokola, preko čitalnika kartic, aplikacije ali ročne izdaje.

Visokonivojski protokoli dodajajo podatkovni kanal. ISO 15118 in njegov predhodnik DIN 70121 vodita strukturiran pogovor prek električnega omrežja: vozilo se identificira, obe strani si izmenjujeta zmogljivosti, vozilo pove, kaj želi, polnilec pa poroča, kaj lahko zagotovi. Izmenjava poteka skozi celotno sejo, zato polnilec vidi zahtevo vozila, ne le nastalega toka.

Kasnejše izdaje ISO 15118 to razširijo na identiteto na podlagi certifikatov, kar omogoča samodejno avtorizacijo, ter na dvosmerni prenos energije. Obe razširitvi zahtevata strojno in programsko opremo, ki je polnilec, izdelan samo po prejšnji izdaji, nima.

Ta plast je tista, kjer v sistem vstopajo značilnosti vozila. Prav tako je tam, kjer dokumentacija polnilca običajno navaja dve ločeni stvari: kateri visokonivojski protokol komunicira z vozilom in kateri backend protokol posreduje navzgor.

Med Charger in Backend

Prevladujoč protokol tukaj je OCPP, odprt standard, ki ga vzdržuje industrijsko združenje in ga neodvisno izvajajo proizvajalci polnilcev ter backend platforme. Določa sporočila za avtorizacijo, začetek in zaustavitev transakcij, vrednosti števcev, obvestila o stanju, oddaljene ukaze, posodobitve vdelane programske opreme in konfiguracijo.

Kasnejše različice OCPP dodajajo upravljanje naprav, izboljšane pametne profile polnjenja in bolj strukturiran pristop k sestavljanim urnikom. Praktična razlika za operaterja je, koliko nadzora ima backend nad tem, kdaj in kako hitro se vsak konektor polni, ter koliko tega je mogoče spremeniti brez obiska lokacije.

Kar OCPP ne počne, je, da govori z vozilom. Backend, ki podpira najnovejšo različico, še vedno spozna vozilo iz druge roke. Če polnilec ne poroča vrednosti, je zaledje ne more prikazati, in nobena platformna sofisticiranost je ne obnovi.

Skladnost doda dodatno plast zmede. Skladnost z OCPP je certificirana za polnilec glede na določeno različico, certifikat pa pripada temu izdelku in tej različici. Ne omenja protokola na strani vozila in ne pove, kako dobro določen backend izvaja isto različico. Dva skladna izdelka še vedno ne moreta medsebojno delovati na opcijskih delih specifikacije, zato integracijsko testiranje obstaja kot ločena dejavnost.

Zakaj plug and charge potrebuje obe strani

Samodejna avtorizacija, običajno opisana kot plug and charge, je veriga in ne funkcija. Vozilo ima pogodbeno potrdilo o visokem protokolu. Polnilec ga potrdi glede na verigo potrdil, ki ji zaupa, in bodisi lokalno odobri identiteto bodisi posreduje identiteto navzgor za odločitev. Backend potrdi, da je pogodba veljavna in da jo je mogoče zaračunati.

Vsaka povezava mora biti prisotna. Vozilo brez pogodbenega potrdila ga ne more predložiti. Polnilec brez visokonivojskega protokola in zaupanja vrednega skladišča tega ne more prebrati. Backend brez ustrezne obdelave certifikatov tega ne more urediti. Ko manjka katerakoli povezava, se seja vrne na kartico, aplikacijo ali QR kodo — kar je točno tisto, kar vozniki doživljajo na omrežjih, ki oglašujejo samodejno polnjenje in ga zagotavljajo le za nekatere kombinacije vozil in operaterjev.

Zato je funkcija v praksi neenakomerno dostopna. To je odvisno od presečišča treh neodvisno posodobljenih sistemov, pri čemer je presek manjši od katerega koli izmed njih.

nadgradnja ene ne nadgradi druge

Štiri pogoste predpostavke ne veljajo iz istega razloga.

Da novejši backend protokol samodejno avtorizira. Ne gre, ker avtorizacija potuje po spodnjem skladu. Polnilec lahko podpira najnovejšo različico v ozadju in še vedno potrebuje kartico.

Da vozilo, ki podpira samodejno polnjenje, deluje na katerem koli omrežju. Deluje tako, da sta polnilec in ozadje konfigurirana za to, operater pa ima gostovanje ali pogodbeni odnos s ponudnikom vozila.

Da posodobitev vdelane programske opreme polnilca doda funkcionalnost na strani vozila. Vidik pogovora o polnilcu je mogoče posodobiti. Vozilo ne more, iz polnilca.

In ta certifikat pokriva oboje. Certifikati se izdajajo za vsak izdelek, protokol in različico, certifikat, ki poimenuje eno plast, pa o drugi ne pove ničesar.

Dobro določen polnilec določa obe plasti ločeno, izdelki v tem razponu pa običajno navajajo različico protokola v ozadju poleg protokolov na strani vozila, ki jih podpirajo. Slog 120 in 180 kW specifikacija postaje to omogoča, prav ta ločitev pa naredi obe zahtevi posamezno testirani.

Kako to vključiti v zahtevo

Zahteva, ki je ni mogoče testirati, ni zahteva. Štiri črte omogočajo testiranje.

Navedite protokol na strani vozila in izdajo, ki ju mora polnilec podpirati, ter ali je na tem vmesniku potrebna samodejna avtorizacija. Navedite protokol in različico v ozadju ter ali je treba skladnost potrditi ali zgolj deklarirati. Navedite rezervno vedenje, ko katera koli pogajanja propadejo, saj je stran, ki tiho preklopi v način brez avtentikacije, problem prihodkov. In navedite, kateri dokazi so sprejeti: številka certifikata, testno poročilo ali skupni test s platformo, ki jo operater namerava uporabljati.

Zadnji od teh je tisti, ki ujame večino projektov. Testiranje skladnosti dokazuje, da izdelek ustreza specifikaciji. Integracijsko testiranje dokazuje, da dva izdelka delujeta skupaj. Dokumenti za nabavo pogosto zahtevajo prvo in potrebujejo drugo, vrzel pa postane vidna šele po dostavi strojne opreme.

Povezava med temi protokoli in upravljanjem obremenitve je dovolj tesna, da povzroči zmedo: pameten profil polnjenja, dostavljen prek protokola v ozadju, je ukaz polnilcu, ki ga mora nato spoštovati znotraj vsega, kar vozilo sprejme. Ta interakcija je obravnavana v opombi o upravljanje obremenitve, ki opisuje, kje se ukaz konča in začnejo omejitve vozila.

Za večino operaterjev je praktična posledica kontrolni seznam in ne prenova. Zapišite obe zahtevi protokola v ločenih vrsticah, poimenujte različico za vsakega, vprašajte, kaj se zgodi, ko pogajanja spodletijo, in preizkusite kombinacijo pred odprtjem strani, ne po prvi pritožbi.