Nabíječka sedí mezi dvěma konverzacemi, které se nesetkají. Na jedné straně komunikuje s vozidlem o tom, kolik proudu má vzít a kdo platí. Na druhé straně komunikuje s backendem o relacích, měřičích a vzdálených příkazech. Oba používají odlišné protokoly, odlišné datové modely a odlišné certifikační režimy.
Kupující je neustále zaměňují a tato záměna vede k některým z nejdražších nedorozumění při nákupu: specifikaci vyžadující moderní backendový protokol v přesvědčení, že poskytuje nabíjení, nebo upgrade vozidla, který má vyřešit problém s fakturací. Oddělení vrstev umožňuje ověřit každý požadavek samostatně.
Dva stohy, dvě úlohy
Spodní stoh vede přes nabíjecí kabel. Zajišťuje fyzické připojení, bezpečnostní kontroly před připojením napájení, vyjednávání nabíjecích parametrů a — v pozdějších verzích — identitu vozidla a výměnu certifikátů, která umožňuje automatickou autorizaci.
Horní zásobník běží přes síťové připojení, obvykle mobilní data nebo lokální LAN. Obsahuje to, co operátor potřebuje: příkazy start a stop, záznamy transakcí, hodnoty měřiče, diagnostiku, správu firmwaru a konfiguraci. Nemá přímý výhled na vozidlo. Všechno, co ví o sezení, se naučil z nabíječky.
Ta asymetrie je klíčem k celému tématu. Nabíječka je překladač s vlastními názory, ne průhledná trubka. Co backend zaznamenává, je to, co nabíječka zvolila k hlášení, v formátu, který definuje horní protokol.
Mezi vozidlem a Chargerem
Starší uspořádání je jednoduché a stále univerzální jako záložní řešení. Signál modulovaný šířkou pulzu na pilotu řízení přenáší maximální proud, vozidlo reaguje změnou úrovně napětí a nabíječka uzavírá svůj stykač, když to sekvence dovolí. Neexistuje žádný datový kanál v moderním smyslu ani výměna identity. Autorizace probíhá mimo protokol, prostřednictvím čtečky karet, aplikace nebo ručního uvolnění.
Vysoce úrovňové protokoly přidávají datový kanál. ISO 15118 a jeho předchůdce DIN 70121 vedou strukturovanou komunikaci přes powerline: vozidlo se identifikuje, obě strany si vyměňují schopnosti, vozidlo sděluje, co chce, a nabíječka hlásí, co může dodat. Výměna pokračuje po celou dobu sezení, proto nabíječka vidí požadavek vozidla, nikoli jen výsledný proud.
Pozdější vydání ISO 15118 rozšiřují toto na identitu založenou na certifikátech, což umožňuje automatickou autorizaci, a na obousměrný přenos energie. Obě rozšíření vyžadují hardware a software, který nabíječka vyrobená pouze pro dřívější edici nemá.
Tato vrstva je místem, kde do systému vstupují charakteristiky vozidla. Je to také místo, kde vlastní dokumentace nabíječky obvykle uvádí dvě samostatné věci: jaký vysoce úrovňový protokol komunikuje s vozidlem a jaký backendový protokol předkládá směrem nahoru.
Mezi Charger a Backendem
Dominantním protokolem je zde OCPP, otevřený standard spravovaný průmyslovou asociací a implementovaný výrobci nabíječek a backendovými platformami nezávisle. Definuje zprávy pro autorizaci, zahájení a ukončení transakce, hodnoty měřiče, hlášení o stavu, vzdálené příkazy, aktualizace firmwaru a konfiguraci.
Pozdější verze OCPP přidávají správu zařízení, vylepšené chytré nabíjecí profily a strukturovanější přístup k kompozitním rozvrhům. Praktický rozdíl pro operátora je v tom, kolik kontroly má backend nad tím, kdy a jak rychle se každý konektor nabíjí, a kolik z toho lze změnit bez návštěvy místa.
Co OCPP nedělá, je komunikace s vozidlem. Backend podporující nejnovější verzi se stále učí o vozidle z druhé ruky. Pokud nabíječka nehlásí hodnotu, backend ji nemůže zobrazit a žádná úroveň sofistikovanosti platformy ji neobnoví.
Dodržování přidává další vrstvu zmatku. Shoda s OCPP je certifikována pro nabíječku vůči definované verzi a certifikace patří tomuto produktu i té verzi. Nic se tam nepíše o protokolu na straně vozidla a neříká se ani o tom, jak dobře konkrétní backend implementuje stejnou verzi. Dva kompatibilní produkty mohou stále selhat v interoperaci na volitelných částech specifikace, proto integrační testování existuje jako samostatná činnost.
Proč plug and charge potřebuje obě strany
Automatické autorizování, obvykle popisované jako plug and charge, je řetězec, nikoli funkce. Vozidlo předkládá osvědčení o smlouvě nad vyšším protokolem. Nabíječka ji ověřuje vůči řetězci certifikátů, kterému důvěřuje, a buď autorizuje lokálně, nebo přeposílá identitu nahoru pro rozhodnutí. Backend potvrzuje, že smlouva je platná a může být fakturována.
Každý odkaz musí být přítomen. Vozidlo bez smluvního osvědčení ho nemůže předložit. Nabíječka bez vysoce úrovňového protokolu a důvěryhodného úložiště to nemůže přečíst. Backend bez příslušného zpracování certifikátů to nemůže vyřešit. Když chybí jakýkoli odkaz, relace se vrací k kartě, aplikaci nebo QR kódu — což je přesně to, co řidiči zažívají na sítích, které propagují automatické nabíjení a poskytují ho pouze pro některé kombinace vozidel a provozovatelů.
To je také důvod, proč je tato funkce v praxi nerovnoměrně dostupná. Závisí na průniku tří nezávisle aktualizovaných systémů a průnik je menší než kterýkoli z nich.
Upgrade jednoho nemění druhý
Čtyři běžné předpoklady selhávají ze stejného důvodu.
Novější backendový protokol automaticky autorizuje. Ne, protože autorizace cestuje na spodním zásobníku. Nabíječka může ovládat nejnovější backendovou verzi a stále potřebovat kartu.
Že vozidlo podporující automatické nabíjení funguje na jakékoli síti. Funguje tam, kde jsou nabíječka a backend nastaveny a provozovatel má roamingový nebo smluvní vztah s poskytovatelem vozidla.
Aktualizace firmwaru nabíječky přidává možnost na straně vozidla. Část konverzace o nabíječce může být aktualizována. Vozidlo nemůže, z nabíječky.
A tato certifikace pokrývá obojí. Certifikace jsou vydávány pro každý produkt, protokol a verzi, a certifikát pojmenující jednu vrstvu o druhé neříká.
Dobře specifikovaná nabíječka uvádí obě vrstvy samostatně a produkty v této řadě obvykle uvádějí backendovou verzi protokolu vedle protokolů na straně vozidla, které podporují. Styl 120 a 180 kW specifikace stanice to dělá a právě toto oddělení činí tyto dvě požadavky samostatně testovatelnými.
Jak to napsat do požadavku
Požadavek, který nelze testovat, není požadavkem. Čtyři řádky to činí testovatelným.
Uveďte protokol na straně vozidla a verzi, kterou nabíječka musí podporovat, a zda je na tomto rozhraní vyžadována automatická autorizace. Uveďte backendový protokol a verzi a zda je třeba certifikovat shodu, nebo pouze deklarovat. Uveďte záložní chování, když některá z jednání selžou, protože stránka, která tiše přejde do neautentizovaného režimu, je problém s příjmy. A uveďte, jaké důkazy jsou přijímány: číslo certifikátu, testovací zprávu nebo společný test s platformou, kterou chce provozovatel používat.
Poslední z nich zachytí většinu projektů. Testování shody dokazuje, že produkt odpovídá specifikaci. Integrační testování dokazuje, že dva produkty spolupracují. Nákupní dokumenty často požadují první a potřebují druhé, a mezera se objeví až po dodání hardwaru.
Vztah mezi těmito protokoly a řízením zátěže je natolik úzký, že způsobuje vlastní zmatek: chytrý nabíjecí profil doručený přes backend protokol je instrukce nabíječce, která ji pak musí respektovat v rámci toho, co vozidlo přijímá. Tato interakce je popsána v poznámce na řízení zátěže, které popisuje, kde končí instrukce a začínají limity vozidla.
Jedna vrstva směřuje k vozidlu, druhá k platformě a žádná nemůže nahradit druhou. Když nějaká funkce chybí, první otázkou je, na který zásobník měla dorazit.
Pro většinu operátorů je praktickým důsledkem kontrolní seznam, nikoli přepracování. Napište požadavky na dva protokoly na samostatné řádky, pojmenujte verzi pro každý z nich, zeptejte se, co se stane, když jednání selže, a otestujte kombinaci před otevřením stránky, nikoli po první stížnosti.
Kontrolujete, co nabíječka vlastně podporuje?
Požádejte o protokol na straně vozidla a backend protokol jako dvě samostatné řádky, každá se svou verzí. Jeden certifikát nepokrývá obě možnosti.
Zeptat se na specifikaci