Ajoneuvoprotokolla vs taustajärjestelmä: Kaksi erillistä pinoa

Laturi sijaitsee kahden keskustelun välissä, jotka eivät kohtaa. Toisella puolella se kertoo ajoneuvolle, kuinka paljon virtaa otetaan ja kuka maksaa. Toisaalta se keskustelee taustajärjestelmän kanssa istunnoista, mittareista ja etäkomennoista. Molemmat käyttävät erilaisia protokollia, erilaisia tietomalleja ja erilaisia sertifiointijärjestelmiä.

Ostajat sekoittavat ne jatkuvasti, ja sekoitus aiheuttaa joitakin hankintojen kalleimmista väärinkäsityksistä: spesifikaatio, joka vaatii modernin backend-protokollan, koska uskotaan, että se tarjoaa plug and charge, tai ajoneuvon päivitys, jonka odotetaan korjaavan laskutusongelma. Kerrosten erottaminen tekee jokaisesta vaatimuksesta tarkistettavan itsenäisesti.

Kaksi pinoa, kaksi tehtävää

Alempi pino kulkee latauskaapelin yli. Se hoitaa fyysisen liitännän, turvallisuustarkastukset ennen virran syöttöä, latausparametrien neuvottelun sekä — myöhemmissä versioissaan — ajoneuvon identiteetin ja automaattisen valtuutuksen mahdollistavan varmenteenvaihdon.

Ylempi pino toimii verkkoyhteyden kautta, yleensä mobiilidatan tai sivuston LAN-verkon kautta. Se sisältää käyttäjän tarvitsemat tiedot: käynnistys- ja pysäytyskomennot, tapahtumatiedot, mittariarvot, diagnostiikan, laiteohjelmiston hallinnan ja konfiguroinnin. Siitä ei ole suoraa näkymää ajoneuvoon. Kaiken, mitä se tietää sessiosta, se oppi laturista.

Tuo epäsymmetria on koko aiheen avain. Laturi on kääntäjä, jolla on omat mielipiteensä, ei läpinäkyvä putki. Se, mitä taustajärjestelmä tallentaa, on se, mitä laturi valitsi raportoida, ylemmän protokollan määrittelemässä muodossa.

Ajoneuvon ja laturin välillä

Vanhempi järjestely on yksinkertainen ja silti universaali varasuunnitelmana. Ohjauspilotin pulssin leveyden moduloitu signaali välittää maksimivirran, ajoneuvo reagoi muuttamalla jännitetasoa, ja laturi sulkee kontaktorinsa sekvenssin salliessa. Nykyaikaisessa mielessä ei ole datakanavaa eikä identiteettivaihtoa. Valtuutus tapahtuu protokollan ulkopuolella, kortinlukijan, sovelluksen tai manuaalisen vapautuksen kautta.

Korkean tason protokollat lisäävät datakanavan. ISO 15118 ja sen edeltäjä DIN 70121 käyvät rakenteellista keskustelua sähkölinjaviestinnässä: ajoneuvo tunnistaa itsensä, osapuolet vaihtavat kykyjä, ajoneuvo ilmoittaa mitä haluaa ja laturi raportoi, mitä se voi toimittaa. Vaihto jatkuu koko istunnon ajan, minkä vuoksi laturi näkee ajoneuvon pyynnön pelkän virran sijaan.

Myöhemmissä ISO 15118 -versioissa tämä laajennetaan sertifikaattipohjaiseen identiteettiin, mikä mahdollistaa automaattisen valtuutuksen sekä kaksisuuntaiseen energiansiirtoon. Molemmat laajennukset vaativat laitteistoa ja ohjelmistoa, joita pelkästään aiemman version laturissa ei ole.

Tämä kerros on se, missä ajoneuvon ominaisuudet tulevat järjestelmään. Tällöin laturin oma dokumentaatio yleensä mainitsee kaksi erillistä asiaa: minkä korkean tason protokollan se kommunikoi ajoneuvolle ja minkä taustaprotokollan se puhuu ylöspäin.

Chargerin ja taustajärjestelmän välillä

Hallitseva protokolla tässä on OCPP, avoin standardi, jota ylläpitää teollisuusyhdistys ja jota laturivalmistajat sekä taustaalustat toteuttavat itsenäisesti. Se määrittelee viestit valtuutus-, transaktioiden aloitus- ja pysäytys, mittariarvot, tilailmoitukset, etäkomennot, laiteohjelmistopäivitykset ja asetukset.

Myöhemmät OCPP-versiot lisäävät laitehallinnan, parannetut älykkäät latausprofiilit ja rakenteellisemman lähestymistavan yhdistettyihin aikatauluihin. Käytännön ero operaattorille on siinä, kuinka paljon taustajärjestelmällä on valtaa siitä, milloin ja kuinka nopeasti kukin liitin latautuu, ja kuinka paljon tätä voi muuttaa ilman paikan päällä käyntiä.

Mitä OCPP ei tee, on kommunikoida ajoneuvon kanssa. Uusinta versiota tukeva taustajärjestelmä oppii silti ajoneuvosta käytettynä. Jos laturi ei raportoi arvoa, taustajärjestelmä ei voi näyttää sitä, eikä mikään alustan hienostuneisuus palauta sitä.

Vaatimustenmukaisuus lisää lisää sekaannusta. OCPP-yhteensopivuus on sertifioitu laturille määriteltyä versiota vastaan, ja sertifiointi kuuluu kyseiselle tuotteelle ja kyseiselle versiolle. Siinä ei mainita mitään ajoneuvopuolen protokollasta, eikä siitä, kuinka hyvin tietty taustajärjestelmä toteuttaa saman version. Kaksi yhteensopivaa tuotetta voi silti epäonnistua yhdessä määrittelyn valinnaisissa osissa, minkä vuoksi integraatiotestaus toimii erillisenä toimintana.

Miksi plug and charge vaatii molemmat puolet

Automaattinen valtuutus, jota yleensä kuvataan plug and charge, on ketju eikä ominaisuus. Ajoneuvo esittää sopimustodistuksen korkean tason protokollan yli. Laturi vahvistaa sen luotettavaa varmenneketjua vastaan ja joko valtuuttaa sen paikallisesti tai lähettää henkilöllisyyden ylöspäin päätöstä varten. Taustajärjestelmä vahvistaa, että sopimus on voimassa ja sitä voidaan laskuttaa.

Jokaisen linkin täytyy olla mukana. Ajoneuvo ilman sopimustodistusta ei voi esittää sellaista. Laturi ilman korkean tason protokollaa ja luottamusvarastoa ei pysty lukemaan sitä. Taustajärjestelmä ilman vastaavaa varmenteenkäsittelyä ei voi hoitaa sitä. Kun linkki puuttuu, istunto palautuu kortille, sovellukselle tai QR-koodille — juuri näin kuljettajat kokevat verkkoissa, jotka mainostavat automaattista latausta ja toimittavat sen vain joillekin ajoneuvo- ja kuljettajayhdistelmille.

Siksi ominaisuus on käytännössä epätasaisesti saatavilla. Se riippuu kolmen itsenäisesti päivitetyn järjestelmän risteyksestä, ja leikkaus on pienempi kuin mikään niistä.

Toisen päivittäminen ei päivitä toista

Neljä yleistä oletusta epäonnistuvat samasta syystä.

Uudempi taustaprotokolla tarjoaa automaattisen valtuuksen. Näin ei ole, koska valtuutus kulkee alemmalla pinolla. Laturi voi puhua uusimman backend-version ja silti vaatia kortin.

Että automaattista latausta tukeva ajoneuvo toimii missä tahansa verkossa. Se toimii niin, että laturi ja taustajärjestelmä on konfiguroitu sitä varten ja operaattorilla on roaming- tai sopimussuhde ajoneuvon palveluntarjoajan kanssa.

Että laturin laiteohjelmistopäivitys lisää ajoneuvopuolen ominaisuuden. Laturin puolta keskustelusta voi päivittää. Ajoneuvo ei voi, laturista.

Ja tuo sertifiointi kattaa molemmat. Sertifioinnit myönnetään tuotteittain, protokollakohtaisesti ja versioittain, ja yhden kerroksen nimeäminen ei kerro mitään toisesta.

Hyvin määritellyt laturi ilmoittaa kaksi kerrosta erikseen, ja tämän sarjan tuotteissa tyypillisesti on backend-protokollaversio ajoneuvopuolen protokollien rinnalla, joita ne tukevat. 120 ja 180 kW asemaspesifikaatio tekee tämän, ja ero tekee näistä kahdesta vaatimuksesta erikseen testattavissa.

How to write this to a Requirement

vaatimus, jota ei voida testata, ei ole vaatimus. Neljä viivaa tekee siitä testattavissa.

Ilmoita, mitä ajoneuvon puolen protokolla ja versio laturin tulee tukea, sekä vaaditaanko automaattinen valtuutus kyseisellä rajapinnalla. Ilmoita taustaprotokolla ja versio sekä siitä, täytyykö vaatimustenmukaisuus olla sertifioitu vai pelkästään julistaa. Ilmoita varasuunnitelman käyttäytyminen, kun jompikumpi neuvottelu epäonnistuu, koska sivusto, joka hiljaisesti siirtyy tunnistamattomaan tilaan, on tuloongelma. Ja ilmoita, mitä todisteita hyväksytään: sertifikaattinumero, testiraportti tai yhteinen testi alustan kanssa, jota operaattori aikoo käyttää.

Viimeinen näistä on se, joka tarttuu useimpiin projekteihin. Yhteensopivuustestaus todistaa, että tuote vastaa spesifikaatiota. Integraatiotestaus todistaa, että kaksi tuotetta toimii yhdessä. Hankintadokumenteissa pyydetään usein ensimmäistä ja tarvitaan toinen, ja aukko näkyy vasta laitteiston toimituksen jälkeen.

Näiden protokollien ja kuormanhallinnan välinen suhde on niin läheinen, että se aiheuttaa oman sekaannuksensa: älykäs latausprofiili, joka toimitetaan backend-protokollan kautta, on käsky laturille, joka sitten noudattaa sitä ajoneuvon hyväksymisissä. Tätä vuorovaikutusta käsitellään muistiinpanossa kuormanhallinta, joka kuvaa, missä käsky päättyy ja ajoneuvon omat rajat alkavat.

Useimmille operaattoreille käytännön seuraus on tarkistuslista, ei uudelleensuunnittelu. Kirjoita kaksi protokollavaatimusta eri riveille, nimeä kummankin versio, kysy mitä tapahtuu, kun neuvottelu epäonnistuu, ja testaa yhdistelmä ennen sivuston avautumista ensimmäisen valituksen jälkeen.