RFID-ligipääsu seadistamine ettevõtete elektriautolaadijatele

Et seadistada ettevõtete elektriautolaadijatele RFID-ligipääs, veenduge, et lugeja toetab teie autentimisvahendit, talletage laadija tegelikult edastatav identifikaator, registreerige see väärtus laadimishaldusplatvormil, määrake vajalikud ligipääsuõigused ning katsetage kogu laadimisseanssi. Seejärel kontrollige, mis juhtub ühenduse katkemisel ja kaardi õiguste tühistamisel.

Esitage tootmispartii tellimus pärast seda, kui esinduslik näidis on selle töövoo edukalt läbinud. Õnnestunud kaardilugemine kinnitab ainult osa tulemusest. Vastuvõtuakt peab kinnitama ka õige laadimispunkti, konto, energiakirje ja peatamise toimimise.

See juhend käsitleb ligipääsuhaldust pärast seda, kui kvalifitseeritud paigaldaja on laadimisseadmed paigaldanud ja kasutusele võtnud. See on mõeldud meeskonnale, kes ühendab füüsilised autentimisvahendid laadimishaldussüsteemiga.

Tehke kindlaks, milline süsteem iga otsuse teeb

Võrguühendusega autoriseerimise korral hangib RFID-lugeja identifikaatori, laadimisjaam edastab selle laadimisjaamade haldussüsteemile ehk CSMS-ile ning platvorm tagastab autoriseerimistulemuse. OCPP reguleerib suhtlust jaama ja selle haldussüsteemi vahel. Kaardi ja lugeja vaheline raadioliides on integratsiooni eraldi osa. Vaadake Open Charge Alliance'i protokolliülevaadet.

Määrake igale kihile üks vastutaja. Kaarditarnija saab anda kokkulepitud füüsilise autentimisvahendi ja identifikaatorifaili; laadija integraator kinnitab lugeja toimimise; platvormi operaator juhib kontode registreerimist ja õigusi. Pange enne kasutuselevõttu kirja, kes lahendab mittevastavused.

1. Kinnitage lugeja ja autoriseerimise võimalused

Küsige lugeja spetsifikatsiooni laadija täpse mudeli, riistvaraversiooni ja paigaldatud püsivara kohta. Talletage toetatud kontaktivabad standardid, kasutatav autentimisvahendi režiim ja võimalik seadistatav identifikaatorite teisendamine. Kirjeldus „RFID-toega” jätab need küsimused lahtiseks.

NFC töötab sagedusel 13,56 MHz ning hõlmab mitut kontaktivaba tehnoloogiat, sealhulgas ISO/IEC 14443 Type A, Type B ja ISO/IEC 15693. Seega ei ole üksnes sageduse sobivus täielik ostuspetsifikatsioon. Sobitage tegelik kaarditehnoloogia lugeja teostusega. NFC Forumi tehniline ülevaade selgitab aluseks olevaid protokolle.

Seejärel selgitage välja, mida jaam ja taustsüsteem tegelikult toetavad:

OCPP sertifitseerimist tuleb hinnata funktsioonide kaupa. OCA 2025. aasta detsembri uuendus paigutab Local List Managementi OCPP 2.0.1 Core profiili valikuliste funktsioonide hulka. Seega ei taga uuendatud sertifitseerimisprogramm kohaliku loendi tuge igas sertifitseeritud jaamas. OCA OCPP 2.Lite'i rakendusjuhise C jaotis selgitab samuti, et autoriseerimise vahemälu võib puududa ja teostused võivad toetada erinevaid autoriseerimismeetodeid.

Küsige sertifikaadi ulatust ja võimaluse korral dokumenti Protocol Implementation Conformance Statement ning võrrelge neid paigaldatud tarkvaraga. Hoidke need tõendid koos objekti konfiguratsiooniga.

OCA avaldab praegu OCPP 1.6, 2.0.1 ja 2.1 pakette. Allolevad näited käsitlevad konkreetselt versioone 1.6 ja 2.0.1; 2.1 paigaldise puhul kasutage vastavat spetsifikatsiooni. Kasutuselevõtul või uuendamisel vaadake ametlikke allalaadimisi ja parandusi.

2. Talletage identifikaator tegelikust laadijast

Alustage väikesest selgelt tuvastatavate testkaartide komplektist. Hoidke kaardile trükitud viitenumber elektroonilisest väärtusest lahus: nähtav seerianumber, näiteks CRF-TEST-0042, on kasutajatoele kasulik, kuid selle vastavus taustsüsteemi identifikaatorile tuleb dokumenteerida.

Võrguühendusega OCPP autoriseerimispäringu jaoks on need väljamõeldud identifikaatoriga illustratiivsed sõnumisisu fragmendid:

OCPP 1.6

{"idTag":"04A1B2C3D4E5F7"}

OCPP 2.0.1

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

Fragmentidest on välja jäetud WebSocketi sõnumiraamistus. Ametlikud skeemid lubavad 1.6 idTag-ile kuni 20 märki ja 2.0.1 idToken-i stringile kuni 36 märki; 2.0.1 nõuab ka tokeni tüüpi. Kontrollige vastavust integratsioonis kasutatavale OCPP 1.6 paketile või OCPP 2.0.1 Edition 4 paketile.

Kohalikult autoriseeritud käivitus võib järgida teistsugust sõnumijada. Laske integraatoril määrata, kuhu selles režiimis autentimisvahend ja autoriseerimisotsus salvestatakse.

3. Leppige UID esituskuju kokku enne kaartide importimist

ISO14443 tokeni korral soovitab OCPP 2.0.1 UID baite kuueteistkümnendkujul, bait 0 esimesena. Vanemate toodete toimimist tuleb siiski kontrollida: Wallboxi OCPP aktiveerimisjuhend määrab selles käsitletud toodetele little-endian-järjestusega kuueteistkümnendväärtused ilma eraldajateta. See on tootepõhine juhis, mitte universaalne teisendusreegel. Vaadake OCPP 2.0.1 autoriseerimise jaotist C.1.1 ja Wallboxi aktiveerimisjuhendi lehekülgi 14 ja 20.

Selle väljamõeldud seitsmebaidise jada esituskujud on järgmised:

Tabel näitab teisendusi, mitte nelja taustsüsteemis omavahel asendatavat väärtust. Importige integratsiooni nõutud esituskuju. Baitide pööramine muudab märgipaaride järjestust; üksikmärkide pööramine annab teise tulemuse.

Säilitage kirjalik vastavus tarnijaandmete, jaamalogi ja taustsüsteemi impordivälja vahel. Lisage pikkus baitides, kuueteistkümnend- või kümnendkuju, baidijärjestus, eraldajad ja kõik sõnaselgelt dokumenteeritud teisendused. Hoidke alles töötlemata lähtefail. Vältige dokumenteerimata kärpimist ja puuduvate baitide oletamist.

Kontrollige identifikaatoreid teisendavaid seadmesätteid. Näiteks Wallbox eM4 WebAdmini juhendis on valik „Shorten UIDs” ning hoiatus, et autoriseerimissätteid saab muuta nii kohalikust liidesest kui ka taustsüsteemist. Vaadake Wallbox WebAdmini juhendi lehekülge 23. Pärast mõlema süsteemi ühendamist talletage tegelikult kehtiv konfiguratsioon.

Importige identifikaatoriveerud arvutustabelisse tekstina. Excel võib eemaldada algusnullid ja piirab arvutäpsuse 15 tüvenumbriga; meie kümnendnäites on 16 numbrit. Pärast andmete muutmist rakendatud kuvavorming ei taasta algset identifikaatorit. Järgige Microsofti juhiseid identifikaatoriandmete säilitamiseks.

Kasutage ChargeRFID UID-muundurit esituskujude uurimiseks ning identifikaatorifailide võrdlemise ja kooskõlastamise tööriista tootmis- ja taustsüsteemifailide võrdlemiseks. Enne kogu partiile rakendamist kinnitage pakutud vastavus tegeliku laadijalogiga.

4. Registreerige autentimisvahendid ja määrake ärilised õigused

Looge autentimisvahendi kirje platvormi dokumenteeritud registreerimis- või impordiprotsessiga. Siduge see kavandatud juhi, sõiduki, osakonna või kliendikontoga vastavalt sellele, kuidas teie tegevuses laadimisi omistatakse.

Iga pilootvahendi puhul märkige üles:

Käsitlege neid eraldi vastuvõtuküsimustena. Autentimisvahend võib olla andmebaasis, kuid sellel võib puududa kavandatud asukohaõigus või kontomäärang. Samuti ei tõenda õnnestunud käivitus õige arvelduskokkuleppe rakendumist.

Kasutage registreerimisnimekirja, kus on partiiviide, imporditulemus, erandi põhjus ja ülevaataja. Lahendage duplikaatväärtused ning vastuolulised määrangud enne väljastamist. Kohandage UID-andmete üleandmise malli platvormi tegelikele impordinõuetele; selle näidisrida on testandmed.

Ühiskasutuses sõidukite puhul leppige kokku, kes saab seansi peatada. OCA OCPP 1.6 testjuhtumid käsitlevad sõnaselgelt peatamist käivituskaardiga ning teise kaardiga, mida ühendab sama ülemidentifikaator. Katsetage kavandatud rühmakäitumist. Vaadake OCTT 2026-02 testjuhtumite jaotisi 2.3.1 ja 2.3.2.

5. Määrake selged ühenduseta ligipääsu reeglid

Otsustage, kas laadimine peab jätkuma, kui jaam ei saa haldussüsteemiga ühendust. Piiratud ligipääsuga sõidukipargibaasis on mõistlik lähtereegel lubada katkestuse ajal kavandatud kohalikult autoriseeritud vahendeid ja lükata tundmatud kaardid tagasi. Enne sellele lootmist kinnitage, et seadmed suudavad reeglit rakendada.

Autoriseerimise vahemälu hoiab varasemate andmevahetuste käigus saadud autoriseerimisinfot. Kohalikku autoriseerimisloendit hallatakse ja sünkroonitakse taustsüsteemist. Need on eri mehhanismid. Ühe tühjendamine ei kinnita teise uuendamist. OCPP 1.6 kirjeldab nende omavahelist toimimist spetsifikatsiooni jaotises 3.5.

Need on versioonipõhiste nimede näited integraatoriga arutamiseks, mitte laadijasse kleebitav konfiguratsioonifail:

Nimed ei kinnita, et kõik funktsioonid on teostatud, lubatud või muudetavad. OCPP 2.0.1 kasutab komponentide ja muutujate adresseerimist; iga sätte töö määravad seadmemudel ja asjakohane kasutusjuht. Vaadake Edition 4 autoriseerimise ja viidatud muutujate jaotisi.

Talletage kohaliku loendi maht, uuenduse kinnitus, aegumise käsitlemine, säilimine pärast taaskäivitust ja toimimine täis salvestusruumi korral. Katsetage tuntud autentimisvahendit, mida pole selles jaamas varem kasutatud, ning ka vahendit, mis on seal juba autoriseeritud. Nii saab kindlaks teha, millisele kohalikule mehhanismile paigaldis tegelikult toetub.

Lisage katsesse ühenduse taastamine. Kontrollige, kuidas ühenduseta tehingud taustsüsteemi jõuavad, kuidas neid kooskõlastatakse ning mis juhtub käimasoleva seansiga, kui taustsüsteem pärast ühenduse taastumist selle autentimisvahendi tagasi lükkab. Leppige objekti omanikuga kokku vastuvõetav tegevus- ja finantsrisk.

6. Valige autentimisvahendi turvamudel teadlikult

Küsige, kas lugeja lihtsalt loeb identifikaatorit või teeb autentimisvahendiga krüptograafilise autentimise. Ainult UID-d kasutavas lahenduses ei tõenda sobiva identifikaatori vastuvõtmine krüptograafilise saladuse valdamist. Turvavõimalustega kiibi ostmine annab väärtust vaid siis, kui paigaldatud lugeja ja rakendus neid võimalusi kasutavad.

Kui nõutakse kaardi krüptograafilist autentimist, dokumenteerige toetatud rakendus, võtmete omandiõigus, algseadistusprotsess, asendusprotseduur ja üleminekuvastutus. Hoidke saladused UID-üleandmisfailidest väljas. NIST-i RFID-turvajuhise jaotis 5.3.1 kirjeldab identifikaatorite ja autentimiskontrollide erinevust. See on 2007. aastal avaldatud alusjuhis; toetatud algoritmide ja võtmehaldusmehhanismide valimiseks kasutage praegust tootedokumentatsiooni.

Turvake jaama ja taustsüsteemi ühendus eraldi. OCA praeguse Security Operations Guide'i jaotised 4.2 ja 4.4 kirjeldavad Security Profile 2 kui TLS-i koos Basic Authenticationiga ja Profile 3 kui TLS-i koos kliendisertifikaatidega ning käsitlevad autentimisandmete säilitamist. Kinnitage kasutatav transpordiprofiil, sertifikaatide valideerimine ja jaama autentimisandmete haldus. Need sätted kaitsevad kaardi ja lugeja vahelisest ühendusest erinevat ühendust.

7. Lisage rändlusautoriseerimine vaid teenuse vajaduse korral

Privaatne töökoha paigaldis võib vajada ainult oma platvormi autentimisvahendite registrit. Rändlus lisab veel ühe piiri: laadimisvõrgu operaator ehk CPO peab saama asjakohaselt elektromobiilsusteenuse pakkujalt ehk eMSP-lt autoriseeringu toetatud integratsiooni ja ärikokkuleppe kaudu.

OCPI 2.3.0 tokenikirje sisaldab tokenit omava teenusepakkuja riigi- ja osapoole identifikaatoreid, tokeni UID-d, tüüpi, kehtivust ja lubatud loendisse kandmise reeglit. Reegel ALLOWED_OFFLINE puudutab CPO ja eMSP vahelist suhtlust. Laadija ühenduse katkemine CSMS-iga on eraldi katkestus. Katsetage mõlemat piiri, kui mõlemad on olemas.

Moodul Tokens eristab ka kehtivat tokenit ja konkreetses asukohas lubatud tokenit. Kehtetuks muutmine edastatakse uuendatud tokeniga, millel on valid: false; tokenite kustutamine selle liidese kaudu ei ole vastav mehhanism. Võrrelge ametlikku OCPI 2.3.0 Tokensi moodulit partneriga kokku lepitud versiooniga.

Piloodi jaoks nimetage väljaandja ja osalev võrk, määrake oodatav autoriseerimistee ning kontrollige tekkinud seanssi ja laadimiskirjet. Sama füüsilise kaardi kasutamine eri teenustes nõuab endiselt asjakohast registreerimist, õigusi ja kokkuleppeid.

8. Katsetage kasutuselevõtul kogu ligipääsu elutsüklit

Kasutage testmaatriksit, kuhu oodatavad tulemused on kirja pandud enne katset. Rakendage seda iga erineva riistvara-, püsivara- ja taustsüsteemikonfiguratsiooni puhul ning seejärel kontrollige paigaldatud seadmeid pisteliselt kinnitatud konfiguratsiooni suhtes.

Iga katse kohta säilitage aeg, jaama ja pistiku identifikaatorid, püsivara, testkaardi viide, kehtiv konfiguratsioon, oodatud tulemus, tegelik tulemus ja asjakohane tehingukirje. Peitke isikuandmed tõendites, mida jagatakse väljaspool käitusmeeskonda.

Kaardi kadumisel talletage teate saabumise aeg ning aeg, mil iga ühendatud süsteem muudatuse kinnitas. Ühenduseta jaam ei saa uut tühistust kohe vastu võtta. Tegelik risk sõltub salvestatud autoriseerimisolekust, aegumisreeglitest ja ühenduse taastamise toimimisest. Käsitlege seda ajavahemikku töökorralduses.

Diagnoosige ebaõnnestunud kaardilugemist õigel süsteemipiiril

Koguge ühe ebaõnnestunud katse andmed koos ajatempli ja kaardiviitega ning uurige seejärel tõendeid. Need kontrollid kitsendavad uurimist, eeldamata kõigi tagasilükkamiste puhul sama põhjust.

Süsteemi kasutuselevõtu näide sõidukipargibaasis

Võtame väljamõeldud baasi 60 juhi, 12 laadimispunkti ja kahe laadijamudeliga. Operaator soovib omistada ligipääsu juhtidele eraldi ja piirata seda baasiga, võimaldades kinnitatud juhtidel laadida ka taustsüsteemi katkestuse ajal.

Alustage viie näidisvahendiga. Talletage iga laadijamudeli edastatud identifikaator ja leppige kokku vastavus tarnijafailile. Registreerige näidised pilootkontole, määrake baasi ligipääs ja kinnitage kavandatud kulukoht.

Kui seadmed toetavad hallatavat kohalikku loendit, eellaadige pilootvahendid ja talletage kinnitatud versioon. Selle pakutud reeglistiku puhul jätke tundmatud ühenduseta identifikaatorid keelatuks. Katkestage jaama ühendus CSMS-iga kontrollitud katse käigus, seejärel proovige eellaaditud kaarti, tundmatut kaarti ja tühistatud kaarti, mille aegunud kohalik olek on teadlikult dokumenteeritud. Taastage ühendus ning kontrollige uuendust ja tehingukirjeid.

Tehke mõlemal mudelil võrguühendusega tagasilükkamise, seansi peatamise ja arvelduse katsed. Pärast edukat pilooti võrrelge ja kooskõlastage 60 kaardi tootmisfail taustsüsteemi registriga, lahendage erandid ning jagage kaardid koos lihtsa kaardikaotuse teatamise korraga. Korrake asjakohaseid vastuvõtukatseid pärast olulisi püsivara, lugejarežiimi või platvormi muudatusi.

Küsimused, mis lahendada enne tellimist

Kas RFID-laadimiskaarte tuleb programmeerida?

Lahenduses, mis loeb kaardi olemasolevat UID-d, võib seadistus piirduda selle väärtuse registreerimise ja platvormil ligipääsu määramisega. Kaitstud rakendust kasutav lahendus võib nõuda kaardi isikustamist ja lugeja koordineeritud seadistust. Määratlege täpne lugeja töövoog enne kummagi teenuse tellimist.

Kas olemasolev töötajakaart saab avada ka laadija?

See võib olla võimalik, kui lugeja toetab kaarditehnoloogiat, vajalik identifikaator on saadaval ja püsiv ning platvorm lubab registreerimist. Hankige kaardisüsteemi omaniku nõusolek ja katsetage tegelikke näidiseid. Platvormipõhise registreerimise näitena kirjeldab Easee kontode ja kohalike võtmete dokumentatsioon erinevaid registreerimisulatusi ning hoiatab muutuvate identifikaatorite eest.

Kas üks kaart töötab igas laadimisvõrgus?

Kontrollige kavandatud võrke eraldi. Füüsiline loetavus, autentimisvahendi registreerimine, kontoõigused ja võimalik rändluskokkulepe kuuluvad kõik vastuvõtukriteeriumidesse. Katsetage osalevat võrku, selle asemel et eeldada katvust kaardi välimuse järgi.

Mida peaks kaarditarnija saama?

Andke lugejanõuded, kinnitatud näidisidentifikaatorite vastavus, nähtava nummerduse skeem, materjali- ja trükispetsifikatsioon, kogus ning kokkulepitud andmeedastusvorming. Nimetage taustsüsteemi impordi ja näidiste vastuvõtu eest vastutaja. Kui lahendus seda nõuab, edastage rakenduse saladused eraldi kokku lepitud turvalise algseadistusprotsessi kaudu.

Koostage oma paigaldise näidisspetsifikatsioon

Koondage ühte spetsifikatsiooni laadija mudel ja püsivara, taustsüsteemi nimi ja protokolliversioon, nõutud autentimisvahendi režiim, kinnitatud identifikaatori esituskuju ning kavandatud ühenduseta reeglistik. Vaadake andmete üleandmine läbi ChargeRFID identifikaatoriandmete laboris ja küsige valmis näidiseid oma piloodi jaoks. Enne tootmistellimuse kinnitamist kiitke koos heaks füüsiline autentimisvahend ja kogu selle ligipääsu töövoog.