Ihmiset vertaavat usein REST API:a, MQTT:ta, kojelautoja ja OCPP:tä ikään kuin ne tekisivät saman työn. Eivät tee. Siitä alkaa suuri osa sähköautolaturin ohjauksen hämmennyksestä.
Yksinkertainen mielimalli on tämä:
- OCPP = laturi-alusta-perusta
- kojelauta / sovellus / verkkoportaali = ihmisille suunnattu ohjauskerros
- REST API = ohjelmisto- ja integraatiokerros
- MQTT = tapahtumapohjainen viestikerros tiettyihin edistyneisiin tapauksiin
Kun erotat nuo kerrokset, päätös helpottuu paljon.
Aloita OCPP:stä perustana
Jos laturisi tukee OCPP:tä, sen pitäisi yleensä olla lähtöpisteesi. OCPP on se, mikä pitää laturikerroksen avoimena ja yhteentoimivana. Se on osa, joka yhdistää laturin keskusjärjestelmään, ei se asia, jota asentajasi tai ohjelmistotiimisi välttämättä käyttää päivittäin.
Siksi OCPP ei ole samassa kategoriassa kuin kojelauta, REST API tai MQTT. Se istuu niiden alla.
Jos joustavuus on tärkeää, aloita OCPP-pohjaisella asetelmalla, jonka avulla voit hallita mitä tahansa OCPP-laturia rakentamatta kaikkea uudelleen joka kerta kun laitteisto vaihtuu. Ja jos joku tiimissäsi sekoittaa edelleen protokollan ja taustajärjestelmän, tämä selittäjä OCPP-taustajärjestelmästä kattaa perusteet.
Milloin kojelauta riittää
Suuri osa sähköautolaturin ohjauksesta on edelleen ihmistyötä, ja se on täysin hyväksyttävää.
Jos työnkulku on "joku kirjautuu sisään, tarkistaa laturin, muuttaa asetuksen, ehkä vie dataa", kojelauta on yleensä oikea vastaus. Hyvä verkkoportaali ei ole oikean järjestelmän leluversio. Monille asentajille, operaattoreille ja tukitiimeille se on oikea järjestelmä.
Se pätee erityisesti:
- asunnonomistajille, jotka haluavat käynnistys/pysäytys-hallinnan, aikataulut, aurinkotasauksen ja sessiohistorian
- asentajille, jotka tarvitsevat näkyvyyden, lokit ja nopean puuttumisen
- tukitiimeille, jotka työskentelevät laiteohjelmiston, asetusten ja etätilan kanssa
- pienemmille operaattoreille, jotka haluavat laturin etäohjauksen ja sähköautolaturin seurannan rakentamatta sisäisiä työkaluja
Päivittäiseen käyttöön sähköautojen lataussovellus tai portaali on usein älykkäin valinta. Ja jos tiimisi elää operaatioissa, vikakoodeissa ja tukitehtävissä, materiaali asentajan työnkuluista ja diagnostiikasta näyttää, miksi kojelauta-ensin on usein juuri oikein.
Milloin REST API on oikea seuraava askel
Heti kun toinen järjestelmä tarvitsee lukea laturidataa tai käynnistää toimintoja, olet sähköautojen lataus-API:n alueella.
Se voi tarkoittaa:
- älykodin virtaa, joka reagoi aurinkoenergian tuotantoon
- EMS tai BEMS, joka tarvitsee laturin tilan ja hallinnan
- ERP- tai vuokralaisalusta, joka haluaa sessiodata
- oma sovellus, white-label-tuote tai sisäinen työkalusi
- automaatiot kohteiden, käyttäjien tai latauskäytäntöjen yli
Tässä REST API yleensä voittaa suoran hyppäämisen MQTT:hen. Useimmille tiimeille REST on helpompi ymmärtää, helpompi dokumentoida, helpompi hallinnoida oikeuksin, helpompi testata ja helpompi toimittaa.
Jos todellinen tarve on "lue dataa ja lähetä silloin tällöin komentoja", REST on normaalisti puhtaampi vastaus.
Tässä kohtaa Plugchoice Developers tulee relevantiksi. Tavoite ei ole korvata OCPP:tä. Tavoite on ohjata OCPP-yhdistettyjä latureita käytännöllisen ohjelmistokerroksen kautta. Ja jos haluat nähdä toteutuspuolen ennen sitoutumista, kehittäjädokumentaatio on oikea paikka aloittaa.
Milloin MQTT todella on järkevä
MQTT ei ole kuvitteellista arvoa. Se vain ei ole oletusvastaus jokaiseen sähköautojen latausprojektiin.
Se on järkevä, kun todella haluat tapahtumapohjasta arkkitehtuuria: kevyt pub/sub, telemetrian levitys, erotetut kuluttajat tai IoT-painotteiset mallit, joissa useat järjestelmät reagoivat laturitapahtumiin lähes reaaliajassa. Noissa tapauksissa MQTT voi olla hyvä valinta edistyneisiin integraatioihin.
Mutta monet tiimit pyytävät MQTT:tä, koska se kuulostaa tekniseltä, ei siksi, että heidän käyttötapauksensa todella tarvitsee sitä. Sitten he perivät brokerin asetuksen, aiheiden suunnittelun, tilaajaelinkaarien, virheenkorjauksen monimutkaisuuden ja tapahtumajärjestyksen päänsäryn vain ratkaistakseen ongelman, jonka REST API olisi hoitanut yksinkertaisemmin.
Hyödyllinen nyrkkisääntö:
- jos ihmiset pääasiassa operoivat latureita, käytä kojelautaa
- jos ohjelmisto pääasiassa operoi latureita, aloita REST API:lla
- jos useat järjestelmät todella tarvitsevat pub/sub-tapahtumavirtoja, MQTT saattaa olla vaivan arvoinen
Yleinen virhe: arkkitehtuurileikki
Tätä tapahtuu jatkuvasti.
Asunnonomistaja luulee tarvitsevansa MQTT:ta, kun hän oikeasti tarvitsee kunnollisen sovelluksen. Asentaja pyytää API-pääsyä, vaikka portaali ratkaisisi suurimman osan työstä. Skaalaava operaattori keskittyy hienoihin integraatiomalleihin ennen kuin varmistaa OCPP-yhteentoimivuuden alla.
Se on väärin päin.
Useimpien tiimien pitäisi yksinkertaistaa, ei harrastaa arkkitehtuurileikkiä. Valitse kerros, joka vastaa työtä:
- ihmisten työnkulku -> kojelauta
- ohjelmiston työnkulku -> REST API
- tapahtumapohjainen monikäyttäjä-työnkulku -> MQTT
Ja kaiken alla, pidä OCPP perustana.
Käytännön asetelma, joka pysyy joustavana
Monille todellisille kohteille järkevä pino näyttää tältä:
- OCPP alla laturi-alusta-yhteentoimivuutta varten
- portaali ihmisten hallintaan, asetuksiin ja näkyvyyteen
- REST API päälle, kun ohjelmiston on integroitava tai automatisoitava
- MQTT vain silloin, kun tapahtumapohjainen arkkitehtuuri selkeästi kannattaa
Siksi Plugchoice on käytännöllinen reitti tässä. Voit aloittaa avoimella sähköautolaturin hallinnalla lukittumisen sijaan, käyttää portaalia kun ihmiset tekevät työn ja lisätä ohjelmisto-ohjauksen, kun asetelmasi todella vaatii sitä. Jos tuo kuulostaa suunnaltasi, tutustu avoimiin sähköautolatausintegraatioihin tai mene suoraan API-dokumentaatioon.
Lopputulema
Älä valitse OCPP:n, kojelaudan, REST API:n ja MQTT:n välillä ikään kuin ne olisivat neljä kilpailevaa tuotetta.
Valitse oikea kerros oikeaan työhön.
Aloita OCPP:stä perustana. Käytä kojelautaa, kun ihmiset pääasiassa operoivat latureita. Käytä REST API:a Plugchoicen kautta, kun ohjelmiston on ohjattava tai integroiduttava latureihin. Käytä MQTT:ta vain silloin, kun pub/sub ja tapahtumapohjainen arkkitehtuuri todella kannattavat.
Se on yleensä yksinkertaisin vastaus. Se on yleensä myös tulevaisuudenkestävin.