Protokol vozidla vs backend protokol: Dva samostatné zásobníky

Nabíjačka sedí medzi dvoma konverzáciami, ktoré sa nestretávajú. Na jednej strane komunikuje s vozidlom o tom, koľko prúdu má vziať a kto platí. Na druhej strane komunikuje s backendom o reláciách, meračoch a vzdialených príkazoch. Obe používajú odlišné protokoly, odlišné dátové modely a odlišné certifikačné režimy.

Kupujúci ich neustále zamieňajú, a toto zmiešanie spôsobuje niektoré z najdrahších nedorozumení pri obstarávaní: špecifikáciu, ktorá vyžaduje moderný backendový protokol v presvedčení, že poskytuje nabíjanie a pripojenie do počítača, alebo vylepšenie vozidla, ktoré má vyriešiť problém s fakturáciou. Oddelením vrstiev je každá požiadavka kontrolovateľná samostatne.

Dva stohy, dve úlohy

Dolný stoh prechádza cez nabíjací kábel. Zabezpečuje fyzické pripojenie, bezpečnostné kontroly pred pripojením napájania, vyjednávanie parametrov nabíjania a – v neskorších verziách – identitu vozidla a výmenu certifikátov, ktorá umožňuje automatickú autorizáciu.

Horný zásobník beží cez sieťové pripojenie, zvyčajne mobilné dáta alebo sieťovú sieť. Nesie to, čo operátor potrebuje: príkazy na štartovanie a zastavenie, záznamy transakcií, hodnoty merača, diagnostiku, správu firmvéru a konfiguráciu. Nemá priamy výhľad na vozidlo. Všetko, čo vie o tréningu, sa naučil z nabíjačky.

Táto asymetria je kľúčom k celému predmetu. Nabíjačka je prekladač s vlastnými názormi, nie priehľadná rúra. To, čo backend zaznamenáva, je to, čo sa nabíjačka rozhodla hlásiť, v formáte, ktorý definuje horný protokol.

Medzi vozidlom a nabíjačkou

Staršie usporiadanie je jednoduché a stále univerzálne ako záložný plán. Signál modulovaný šírkou impulzu na riadiacom pilote prenáša maximálny prúd, vozidlo reaguje zmenou úrovne napätia a nabíjačka zatvára kontaktor, keď to sekvencia umožňuje. V modernom zmysle neexistuje dátový kanál ani výmena identity. Autorizácia prebieha mimo protokolu, prostredníctvom čítačky kariet, aplikácie alebo manuálneho uvoľnenia.

Vysokoúrovňové protokoly pridávajú dátový kanál. ISO 15118 a jeho predchodca DIN 70121 vedú štruktúrovanú komunikáciu cez powerline: vozidlo sa identifikuje, obe strany si vymieňajú schopnosti, vozidlo povie, čo chce, a nabíjačka oznámi, čo môže dodať. Výmena pokračuje počas celej relácie, preto nabíjačka vidí požiadavku vozidla, nielen výsledný prúd.

Neskoršie vydania ISO 15118 rozširujú toto na identitu založenú na certifikátoch, čo umožňuje automatickú autorizáciu, a na obojsmerný prenos energie. Obe rozšírenia vyžadujú hardvér a softvér, ktorý nabíjačka vyrobená len podľa skoršej edície nemá.

Táto vrstva je miestom, kde do systému vstupujú charakteristiky vozidla. Je to tiež miesto, kde dokumentácia nabíjačky zvyčajne uvádza dve samostatné veci: ktorý vysokoúrovňový protokol komunikuje s vozidlom a ktorý backendový protokol vysiela smerom nahor.

Medzi Chargerom a backendom

Dominantným protokolom je tu OCPP, otvorený štandard udržiavaný priemyselnou asociáciou a nezávisle implementovaný výrobcami nabíjačiek a backendovými platformami. Definuje správy pre autorizáciu, začiatok a zastavenie transakcie, hodnoty merača, hlásenia o stave, vzdialené príkazy, aktualizácie firmvéru a konfiguráciu.

Neskoršie verzie OCPP pridávajú správu zariadení, vylepšené inteligentné nabíjacie profily a štruktúrovanejší prístup k kompozitným rozvrhom. Praktický rozdiel pre operátora je v tom, koľko kontroly má backend nad tým, kedy a akou rýchlosťou sa každý konektor nabíja, a koľko z toho sa dá zmeniť bez návštevy miesta.

OCPP nekomunikuje s vozidlom. Backend, ktorý podporuje najnovšiu verziu, sa stále učí o vozidle z druhej ruky. Ak nabíjačka nehlási hodnotu, backend ju nemôže zobraziť a žiadna úroveň sofistikovanosti platformy ju neobnoví.

Súlad pridáva ďalšiu vrstvu zmätku. Zhoda OCPP sa certifikuje pre nabíjačku voči definovanej verzii a certifikácia patrí tomuto produktu a tej verzii. Nič sa nehovorí o protokole na strane vozidla a nič o tom, ako dobre konkrétny backend implementuje tú istú verziu. Dva kompatibilné produkty môžu stále nespolupracovať na voliteľných častiach špecifikácie, preto integračné testovanie existuje ako samostatná činnosť.

Prečo plug and charge potrebuje obe strany

Automatická autorizácia, zvyčajne označovaná ako plug and charge, je reťazec, nie funkcia. Vozidlo predkladá zmluvné osvedčenie nad vysokoúrovňovým protokolom. Nabíjač ho overuje voči reťazcu certifikátov, ktorému dôveruje, a buď autorizuje lokálne, alebo preposiela identitu vyššie na rozhodnutie. Backend potvrdzuje, že zmluva je platná a môže byť fakturovaná.

Každý odkaz musí byť prítomný. Vozidlo bez zmluvného osvedčenia ho nemôže predložiť. Nabíjačka bez vysokoúrovňového protokolu a dôveryhodného úložiska ho nedokáže prečítať. Backend bez príslušného spracovania certifikátov to nemôže vyriešiť. Keď chýba akýkoľvek odkaz, relácia sa vracia k karte, aplikácii alebo QR kódu — čo je presne to, čo vodiči zažívajú na sieťach, ktoré propagujú automatické nabíjanie a poskytujú ho len pre niektoré kombinácie vozidla a prevádzkovateľa.

Preto je táto funkcia v praxi nerovnomerne dostupná. Závisí od prieniku troch nezávisle aktualizovaných systémov a prienik je menší ako ktorýkoľvek z nich.

Vylepšenie jedného nezvyšuje druhý

Štyri bežné predpoklady zlyhávajú z rovnakého dôvodu.

Že novší backendový protokol poskytuje automatickú autorizáciu. Nerobí to, pretože autorizácia cestuje na spodnom zásobníku. Nabíjačka môže ovládať najnovšiu backendovú verziu a stále vyžaduje kartu.

Že vozidlo podporujúce automatické nabíjanie funguje v akejkoľvek sieti. Funguje tam, kde sú nabíjačka a backend nastavené a operátor má roamingový alebo zmluvný vzťah s poskytovateľom vozidla.

Aktualizácia firmvéru nabíjačky pridáva možnosť na strane vozidla. Časť rozhovoru o nabíjačke sa dá aktualizovať. Vozidlo nemôže, z nabíjačky.

A táto jedna certifikácia pokrýva oboje. Certifikácie sa vydávajú pre každý produkt, protokol a verziu, a certifikát pomenujúci jednu vrstvu o druhej vrstve nič nehovorí.

Dobre špecifikovaná nabíjačka uvádza obe vrstvy samostatne a produkty v tomto rade zvyčajne uvádzajú backendovú verziu protokolu spolu s protokolmi na strane vozidla, ktoré podporujú. Štýl 120 a 180 kW špecifikácia stanice to robí tieto dve požiadavky testovateľnými samostatne.

Ako to napísať do požiadavky

Požiadavka, ktorú nie je možné otestovať, nie je požiadavkou. Štyri čiary ho robia testovateľným.

Uveďte protokol na strane vozidla a verziu, ktorú musí nabíjačka podporovať, a či je na danom rozhraní potrebná automatická autorizácia. Uveďte backendový protokol a verziu, a či musí byť zhoda certifikovaná alebo len deklarovaná. Uveďte záložné správanie, keď niektorá z rokovaní zlyhá, pretože stránka, ktorá ticho prejde do neautentifikovaného režimu, je problém s príjmami. A uveďte, aké dôkazy sú akceptované: číslo certifikátu, testovaciu správu alebo spoločný test s platformou, ktorú chce prevádzkovateľ použiť.

Posledný z nich je ten, ktorý zachytáva väčšinu projektov. Testovanie zhody dokazuje, že produkt spĺňa špecifikáciu. Testovanie integrácie dokazuje, že dva produkty spolupracujú. Obstarávacie dokumenty často požadujú prvú možnosť a potrebujú druhú, pričom medzera sa objaví až po dodaní hardvéru.

Vzťah medzi týmito protokolmi a riadením záťaže je dostatočne úzky na to, aby spôsobil vlastné zmätky: inteligentný nabíjací profil doručený cez backend protokol je inštrukcia nabíjačke, ktorá ju potom musí rešpektovať v rámci toho, čo vozidlo akceptuje. Táto interakcia je spracovaná v poznámke o riadenie záťaže, ktoré popisuje, kde končí inštrukcia a začínajú vlastné limity vozidla.

Pre väčšinu operátorov je praktickým dôsledkom kontrolný zoznam namiesto prepracovania. Napíšte dve požiadavky protokolu na samostatné riadky, pomenujte verziu pre každú z nich, opýtajte sa, čo sa stane, keď vyjednávanie zlyhá, a otestujte kombináciu pred otvorením stránky, nie po prvej sťažnosti.