RFID-käyttöoikeudet yritysten sähköautolatureihin

Kun otat RFID-käyttöoikeudet käyttöön yritysten sähköautolatureissa, varmista ensin, että lukija tukee lataustunnistetta. Tallenna laturin todella raportoima tunnistearvo, rekisteröi se latausalustalle, määritä tarvittavat käyttöoikeudet ja testaa koko lataustapahtuma. Testaa sen jälkeen, mitä tapahtuu yhteyden katketessa ja kortin käyttöoikeuden peruuttamisen jälkeen.

Tilaa tuotantoerä vasta, kun edustava näyte on läpäissyt tämän menettelyn. Onnistunut kortinluku osoittaa vain osan tuloksesta. Hyväksymispöytäkirjan tulee osoittaa myös oikea latauspiste, tili, energiakirjaus ja lopetuskäyttäytyminen.

Tämä opas käsittelee käyttöoikeuksien hallintaa sen jälkeen, kun pätevä asentaja on asentanut ja ottanut latauslaitteet käyttöön. Se on tarkoitettu tiimille, joka yhdistää fyysiset lataustunnisteet latauksenhallintajärjestelmään.

Selvitä, mikä järjestelmä tekee kunkin päätöksen

Verkkoyhteydellä tehtävässä valtuutuksessa RFID-lukija lukee tunnistearvon, latausasema välittää sen latausasemien hallintajärjestelmälle eli CSMS:lle, ja alusta palauttaa valtuutustuloksen. OCPP ohjaa aseman ja hallintajärjestelmän välistä viestintää. Kortin ja lukijan välinen radiorajapinta on integraation erillinen osa. Katso Open Charge Alliancen protokollakatsaus.

Nimeä kullekin kerrokselle yksi vastuuhenkilö. Korttitoimittaja voi toimittaa sovitun fyysisen lataustunnisteen ja tunnistetiedoston; latausintegraattori vahvistaa lukijan toiminnan; alustan ylläpitäjä hallitsee tilirekisteröintiä ja käyttöoikeuksia. Kirjaa ennen käyttöönottoa, kuka ratkaisee mahdolliset ristiriidat.

1. Varmista lukijan ja valtuutuksen ominaisuudet

Pyydä lukijamääritys täsmälleen kyseiselle laturimallille, laitteistoversiolle ja asennetulle laiteohjelmistolle. Kirjaa tuetut kontaktittomat standardit, käytetty tunnistetila ja mahdolliset määritettävät tunnistearvon muunnokset. Ilmaisu ”RFID-valmius” ei vastaa näihin kysymyksiin.

NFC toimii taajuudella 13.56 MHz ja kattaa useita kontaktittomia tekniikoita, kuten ISO/IEC 14443 Type A:n, Type B:n ja ISO/IEC 15693:n. Pelkkä taajuuden vastaavuus on siis puutteellinen hankintamääritys. Varmista varsinaisen korttitekniikan ja lukijatoteutuksen yhteensopivuus. NFC Forumin tekninen katsaus selittää taustalla olevat protokollat.

Selvitä seuraavaksi, mitä asema ja taustajärjestelmä todella toteuttavat:

OCPP-sertifiointia on tarkasteltava ominaisuuskohtaisesti. OCA:n joulukuun 2025 päivitys sijoittaa Local List Management -toiminnon OCPP 2.0.1 Core -profiilin valinnaisiin ominaisuuksiin. Päivitetty sertifiointiohjelma ei siis takaa, että jokainen sertifioitu asema tukee paikallisia luetteloita. OCA:n OCPP 2.Lite -sovellusohjeen osio C selittää myös, että valtuutusvälimuisti voidaan jättää pois ja että toteutukset voivat tukea eri valtuutusmenetelmiä.

Pyydä sertifikaatin kattavuustiedot sekä Protocol Implementation Conformance Statement, jos se on saatavilla, ja vertaa niitä asennettuun ohjelmistoon. Säilytä aineisto kohteen määritysten yhteydessä.

OCA julkaisee tällä hetkellä OCPP 1.6-, 2.0.1- ja 2.1-paketteja. Alla olevat esimerkit koskevat nimenomaan versioita 1.6 ja 2.0.1; käytä 2.1-asennuksessa vastaavaa määritystä. Tarkista viralliset latauspaketit ja korjausluettelot käyttöönoton tai päivityksen yhteydessä.

2. Tallenna tunnistearvo varsinaisesta laturista

Aloita pienestä joukosta yksilöitävissä olevia testikortteja. Pidä painettu korttiviite erillään sähköisestä arvosta: näkyvä sarjanumero, kuten CRF-TEST-0042, on hyödyllinen tuelle, mutta sen yhteys taustajärjestelmän tunnistearvoon on dokumentoitava.

Seuraavat havainnollistavat hyötykuorman katkelmat esittävät verkkoyhteydellä lähetettävää OCPP-valtuutuspyyntöä kuvitteellisella tunnistearvolla:

OCPP 1.6

{"idTag":"04A1B2C3D4E5F7"}

OCPP 2.0.1

{"idToken":{"idToken":"04A1B2C3D4E5F7","type":"ISO14443"}}

Katkelmista on jätetty pois WebSocket-viestien kehystys. Viralliset skeemat määrittävät 1.6-version idTag-arvon enimmäispituudeksi 20 merkkiä ja 2.0.1-version idToken-merkkijonon enimmäispituudeksi 36 merkkiä; 2.0.1 vaatii myös tunnisteen tyypin. Validoi integraatiossa käytettävää OCPP 1.6 -pakettia tai OCPP 2.0.1 Edition 4 -pakettia vasten.

Paikallisesti valtuutettu käynnistys voi noudattaa toista viestijärjestystä. Pyydä integraattoria osoittamaan, mihin tunniste ja valtuutuspäätös kirjautuvat kyseisessä tilassa.

3. Sovi UID-esitysmuodosta ennen korttien tuontia

ISO14443-tunnisteelle OCPP 2.0.1 suosittelee heksadesimaalisia UID-tavuja tavu 0 ensimmäisenä. Vanhojen tuotteiden toiminta on silti tarkistettava: Wallboxin OCPP-aktivointiopas määrittää sen kattamille tuotteille little-endian-tavujärjestyksen mukaiset heksadesimaaliarvot ilman erottimia. Tämä on tuotekohtainen ohje, ei yleispätevä muunnossääntö. Katso OCPP 2.0.1:n valtuutusosio C.1.1 ja Wallboxin aktivointioppaan sivut 14 ja 20.

Tämän kuvitteellisen seitsemän tavun sarjan esitysmuodot ovat:

Taulukko esittää muunnoksia, ei neljää keskenään vaihdettavaa taustajärjestelmän arvoa. Tuo integraation vaatima esitysmuoto. Tavujen kääntäminen muuttaa järjestystä merkkipareittain; yksittäisten merkkien järjestyksen kääntäminen tuottaa eri tuloksen.

Dokumentoi toimittajatietojen, aseman lokin ja taustajärjestelmän tuontikentän välinen vastaavuus. Sisällytä tavupituus, heksadesimaali- tai desimaaliesitys, tavujärjestys, erottimet ja kaikki nimenomaisesti dokumentoidut muunnokset. Säilytä alkuperäinen raakatiedosto. Vältä dokumentoimatonta katkaisua ja puuttuvien tavujen arvaamista.

Tarkista tunnistearvoja muuntavat laiteasetukset. Esimerkiksi Wallbox eM4 WebAdmin -käsikirjassa on ”Shorten UIDs” -asetus ja varoitus, että valtuutusasetuksia voidaan muuttaa sekä paikallisesta käyttöliittymästä että taustajärjestelmästä. Katso Wallbox WebAdmin -käsikirjan sivu 23. Kirjaa voimassa olevat asetukset sen jälkeen, kun molemmat järjestelmät ovat muodostaneet yhteyden.

Tuo tunnistearvosarakkeet laskentataulukkoon tekstinä. Excel voi poistaa etunollia ja rajoittaa lukujen tarkkuuden 15 merkitsevään numeroon; desimaaliesimerkissämme on 16 numeroa. Näyttömuodon muuttaminen tietojen muuttumisen jälkeen ei palauta alkuperäistä tunnistearvoa. Noudata Microsoftin tunnistetietojen säilyttämistä koskevaa ohjetta.

Tutki esitysmuotoja ChargeRFIDin UID-muuntimella ja vertaa tuotanto- ja taustajärjestelmätiedostoja tunnistetiedostojen täsmäytystyökalulla. Vahvista ehdotettu vastaavuus todellisesta laturilokista ennen sen soveltamista koko erään.

4. Rekisteröi lataustunnisteet ja määritä kaupalliset käyttöoikeudet

Luo tunnistetietue alustan dokumentoidun rekisteröinti- tai tuontiprosessin kautta. Liitä se tarkoitettuun kuljettajaan, ajoneuvoon, osastoon tai asiakastiliin sen mukaan, miten toimintanne kohdistaa latauksen.

Kirjaa jokaisesta pilotin lataustunnisteesta:

Pidä nämä erillisinä hyväksymiskysymyksinä. Lataustunniste voi olla tietokannassa ilman tarkoitettua paikkakohtaista käyttöoikeutta tai tililiitosta. Onnistunut käynnistys ei myöskään osoita, että oikeaa laskutusjärjestelyä on sovellettu.

Käytä rekisteröintiluetteloa, jossa on eräviite, tuonnin tulos, poikkeaman syy ja tarkastaja. Ratkaise päällekkäiset arvot ja ristiriitaiset kohdistukset ennen luovutusta. Mukauta UID-luovutuspohja alustan todellisen tuontisopimuksen mukaiseksi; esimerkkirivi on testidataa.

Sovi yhteiskäyttöajoneuvojen osalta, kuka saa lopettaa lataustapahtuman. OCA:n OCPP 1.6 -testitapaukset kattavat nimenomaisesti lopettamisen aloituskortilla sekä toisella kortilla, jonka yhdistää sama ylemmän tason tunniste. Testaa ryhmätoiminta, jonka aiotte ottaa käyttöön. Katso OCTT 2026-02 -testitapausten osiot 2.3.1 ja 2.3.2.

5. Määritä selkeä offline-käyttöoikeuskäytäntö

Päätä, sallitaanko lataus, kun asema ei saa yhteyttä hallintajärjestelmään. Rajatun ajoneuvovarikon järkevä lähtökohta on sallia tarkoitetut paikallisesti valtuutetut lataustunnisteet ja hylätä tuntemattomat kortit katkon aikana. Varmista ennen käytäntöön luottamista, että laitteisto pystyy toteuttamaan sen.

Valtuutusvälimuisti sisältää aiemmasta viestinvaihdosta saatuja valtuutustietoja. Paikallista valtuutusluetteloa hallitaan ja synkronoidaan taustajärjestelmästä. Nämä ovat erillisiä mekanismeja. Toisen tyhjentäminen ei osoita, että toinen on päivitetty. OCPP 1.6 kuvaa niiden suhdetta määrityksen osiossa 3.5.

Nämä ovat esimerkkejä versiokohtaisista nimistä integraattorin kanssa käsiteltäviksi, eivät laturiin liitettävä määritystiedosto:

Nimet eivät tarkoita, että kaikki ominaisuudet olisi toteutettu, otettu käyttöön tai muutettavissa. OCPP 2.0.1 käyttää komponenttien ja muuttujien osoitusta; laitemalli ja sovellettava käyttötapaus määräävät asetusten toiminnan. Katso Edition 4:n valtuutusta ja viitattuja muuttujia käsittelevät osiot.

Kirjaa paikallisen luettelon kapasiteetti, päivityskuittaus, voimassaolon päättymisen käsittely, säilyvyys uudelleenkäynnistyksen jälkeen ja toiminta tallennustilan täyttyessä. Testaa sekä tunnettua lataustunnistetta, jota ei ole koskaan käytetty asemalla, että siellä jo valtuutettua tunnistetta. Näin selviää, mihin paikalliseen mekanismiin toteutus todella perustuu.

Sisällytä testiin yhteyden palautuminen. Tarkista, miten offline-tapahtumat saapuvat taustajärjestelmään ja täsmäytetään sekä mitä käynnissä olevalle lataustapahtumalle tapahtuu, jos taustajärjestelmä hylkää tunnisteen yhteyden palauduttua. Sovi kohteen omistajan kanssa hyväksyttävästä toiminnallisesta ja taloudellisesta riskistä.

6. Valitse lataustunnisteen turvallisuusmalli tietoisesti

Kysy, lukeeko lukija vain tunnistearvon vai tekeekö se kryptografisen todennuksen lataustunnisteen kanssa. Pelkkään UID-arvoon perustuvassa mallissa vastaavan arvon hyväksyminen ei osoita kryptografisen salaisuuden hallussapitoa. Turvaominaisuuksilla varustetun sirun ostamisesta on hyötyä vain, jos käytössä oleva lukija ja sovellus hyödyntävät niitä.

Kun kryptografista kortin todennusta vaaditaan, dokumentoi tuettu sovellus, avainten omistus, valmistelu- ja määritysprosessi, vaihtomenettely sekä siirtovastuut. Pidä salaisuudet poissa UID-luovutustiedostoista. NISTin RFID-turvaohjeen osio 5.3.1 kuvaa tunnistearvojen ja todennusmekanismien eron. Kyseessä on vuonna 2007 julkaistu perustavanlaatuinen ohje; käytä ajantasaista tuotedokumentaatiota tuettujen algoritmien ja avaintenhallintamekanismien valintaan.

Suojaa aseman ja taustajärjestelmän yhteys erikseen. OCA:n nykyinen Security Operations Guide, osiot 4.2 ja 4.4, kuvaa Security Profile 2:n TLS-yhteydeksi Basic Authentication -todennuksella ja Profile 3:n TLS-yhteydeksi asiakasvarmenteilla sekä käsittelee todennustietojen säilytystä. Varmista käytössä oleva siirtoyhteyden profiili, varmenteiden validointi ja aseman todennustietojen hallinta. Nämä asetukset suojaavat eri yhteyttä kuin kortin ja lukijan välinen yhteys.

7. Lisää verkkovierailuvaltuutus vain palvelun sitä edellyttäessä

Yksityinen työpaikkalataus voi tarvita vain oman alustansa lataustunnisterekisterin. Verkkovierailu lisää uuden rajapinnan: latausoperaattorin eli CPO:n on saatava valtuutus asianomaiselta sähköisen liikkumisen palveluntarjoajalta eli eMSP:ltä tuetun integraation ja kaupallisen sopimuksen kautta.

OCPI 2.3.0:ssa tunnistetietue sisältää omistavan palveluntarjoajan maa- ja osapuolitunnukset sekä tunnisteen UID-arvon, tyypin, voimassaolon ja sallittujen tunnisteiden luetteloa koskevan käytännön. Sen ALLOWED_OFFLINE-käytäntö koskee CPO:n ja eMSP:n välistä viestintää. Laturin CSMS-yhteyden katkeaminen on eri häiriö. Testaa molemmat rajapinnat, jos molemmat ovat käytössä.

Tokens-moduuli erottaa myös voimassa olevan tunnisteen tietyssä paikassa sallitusta tunnisteesta. Mitätöinti välitetään päivittämällä tunnisteeseen valid: false; tunnisteiden poistaminen tämän rajapinnan kautta ei ole käytetty mekanismi. Tarkista virallinen OCPI 2.3.0 Tokens -moduuli kumppaninne kanssa sovittua versiota vasten.

Nimeä pilotissa myöntäjä ja osallistuva verkko, selvitä odotettu valtuutuspolku ja tarkista syntyvä lataustapahtuma ja lataustietue. Saman fyysisen kortin käyttäminen eri palveluissa edellyttää edelleen asianmukaista rekisteröintiä, käyttöoikeuksia ja sopimuksia.

8. Ota käyttöön koko käyttöoikeuksien elinkaari

Käytä testimatriisia, jonka odotetut tulokset kirjataan ennen testiä. Suorita se jokaisella erillisellä laitteiston, laiteohjelmiston ja taustajärjestelmän kokoonpanolla ja tarkista sitten asennettua laitekantaa pistokokein hyväksyttyä kokoonpanoa vasten.

Säilytä jokaisesta testikerrasta aika, aseman ja liittimen tunnukset, laiteohjelmisto, testikortin viite, voimassa olevat asetukset, odotettu tulos, toteutunut tulos ja asianomainen tapahtumatietue. Peitä henkilötiedot käyttötiimin ulkopuolelle jaettavasta aineistosta.

Kun kortti katoaa, kirjaa ilmoituksen saapumisaika ja kunkin yhdistetyn järjestelmän kuittausaika. Verkosta irti oleva asema ei voi vastaanottaa uutta sulkua välittömästi. Käytännön riski riippuu tallennetusta valtuutustilasta, voimassaolosäännöistä ja toiminnasta yhteyden palauduttua. Käsittele tämä aikaväli toimintaohjeessa.

Paikanna epäonnistunut kortinluku oikeaan rajapintaan

Tallenna yksi epäonnistunut yritys aikaleimoineen ja korttiviitteineen ja käy sitten näyttö läpi. Nämä tarkistukset rajaavat tutkimusta olettamatta kaikkien hylkäysten johtuvan samasta syystä.

Esimerkkikäyttöönotto ajoneuvovarikolla

Kuvitellaan varikko, jolla on 60 kuljettajaa, 12 latauspistettä ja kaksi laturimallia. Operaattori haluaa kohdistaa käytön yksittäisille kuljettajille, rajata sen varikolle ja sallia hyväksyttyjen kuljettajien lataamisen taustajärjestelmän katkon aikana.

Aloita viidellä näytetunnisteella. Tallenna kunkin laturimallin raportoima tunnistearvo ja sovi vastaavuudesta toimittajan tiedostoon. Rekisteröi näytteet pilottitilille, myönnä varikon käyttöoikeus ja vahvista tarkoitettu kustannuspaikka.

Jos laitteisto tukee hallittua paikallista luetteloa, esilataa pilotin tunnisteet ja kirjaa kuitattu versio. Pidä tuntemattomien offline-tunnisteiden käyttö estettynä tässä ehdotetussa käytännössä. Katkaise aseman CSMS-yhteys hallitussa testissä ja kokeile sitten esiladattua korttia, tuntematonta korttia ja suljettua korttia, jonka paikallinen tila on tarkoituksellisesti dokumentoitu vanhentuneeksi. Palauta yhteys ja varmista päivitys- ja tapahtumatietueet.

Suorita verkkoyhteydellä tapahtuvan hylkäyksen, lopetuksen ja laskutuksen testit molemmilla malleilla. Kun pilotti on hyväksytty, täsmäytä 60 kortin tuotantotiedosto taustajärjestelmän rekisteriin, ratkaise poikkeamat ja jaa kortit yhdessä yksinkertaisen katoamisilmoitusmenettelyn kanssa. Toista olennaiset hyväksymistestit merkittävien laiteohjelmisto-, lukijatila- tai alustamuutosten jälkeen.

Ennen tilaamista ratkaistavat kysymykset

Tarvitseeko RFID-latauskortteja ohjelmoida?

Jos toteutus lukee kortin olemassa olevan UID-arvon, käyttöönotto voi koostua arvon rekisteröinnistä ja käyttöoikeuksien määrittämisestä alustalla. Suojattua sovellusta käyttävä toteutus voi edellyttää kortin personointia ja koordinoitua lukijamääritystä. Määritä lukijan täsmällinen toimintakulku ennen kummankaan palvelun tilaamista.

Voiko nykyisellä henkilöstökortilla avata myös laturin?

Se voi olla mahdollista, kun lukija tukee kortin tekniikkaa, tarvittava tunnistearvo on saatavilla ja vakaa ja alusta sallii rekisteröinnin. Hanki korttijärjestelmän omistajan hyväksyntä ja testaa todellisia näytteitä. Esimerkkinä alustakohtaisesta rekisteröinnistä Easeen tili- ja paikallisavainohje kuvaa erillisiä rekisteröinnin laajuuksia ja varoittaa muuttuvista tunnistearvoista.

Toimiiko yksi kortti kaikissa latausverkoissa?

Selvitä tarkoitetut verkot yksitellen. Fyysinen luettavuus, tunnisteen rekisteröinti, tilin käyttöoikeudet ja mahdollinen verkkovierailusopimus kuuluvat kaikki hyväksymiskriteereihin. Testaa osallistuva verkko sen sijaan, että olettaisit kattavuuden kortin ulkonäön perusteella.

Mitä korttitoimittajalle tulee toimittaa?

Toimita lukijavaatimukset, hyväksytty näytetunnisteiden vastaavuus, näkyvä numerointitapa, materiaali- ja painomääritykset, määrä ja sovittu tiedontoimitusmuoto. Nimeä taustajärjestelmätuonnista ja näytteiden hyväksynnästä vastaava henkilö. Siirrä sovellussalaisuudet erikseen sovitun turvallisen valmistelu- ja määritysprosessin kautta, jos toteutus niitä vaatii.

Valmistele näytemääritys käyttöönottoa varten

Kokoa samaan määritykseen laturimalli ja laiteohjelmisto, taustajärjestelmän nimi ja protokollaversio, vaadittu tunnistetila, vahvistettu tunnistearvon esitysmuoto ja tarkoitettu offline-käytäntö. Tarkista tietojen luovutus ChargeRFIDin tunnistelaboratoriossa ja pyydä valmiita näytteitä pilottiin. Hyväksy fyysinen lataustunniste ja sen koko käyttöoikeusprosessi yhdessä ennen tuotantotilauksen vapauttamista.