Uppsetning RFID-aðgangs að hleðslustöðvum fyrirtækja

Til að setja upp RFID-aðgang að hleðslustöðvum fyrirtækja skaltu staðfesta að lesarinn styðji auðkennið, skrá auðkennisgildið sem hleðslustöðin sendir í raun frá sér, skrá það í hleðslukerfið, úthluta nauðsynlegum aðgangsheimildum og prófa alla hleðslulotuna. Prófaðu síðan hvað gerist þegar samband rofnar og þegar kort er afturkallað.

Pantaðu framleiðslulotuna þegar dæmigert sýnishorn hefur staðist þetta ferli. Vel heppnaður kortalestur staðfestir aðeins hluta niðurstöðunnar. Samþykktarskráin ætti einnig að sýna réttan hleðslustað, reikning, orkufærslu og hegðun við stöðvun.

Þessar leiðbeiningar fjalla um aðgangsstýringu eftir að hæfur uppsetningaraðili hefur sett hleðslubúnaðinn upp og tekið hann í notkun. Þær eru ætlaðar teyminu sem tengir efnisleg auðkenni við hleðslustjórnunarkerfi.

Skildu hvaða kerfi tekur hverja ákvörðun

Þegar heimild er veitt í netsambandi les RFID-lesarinn auðkennisgildi, hleðslustöðin sendir það til hleðslustjórnunarkerfis, eða CSMS, og kerfið skilar niðurstöðu heimildaveitingar. OCPP stjórnar samskiptum stöðvarinnar og stjórnunarkerfisins. Þráðlausa viðmótið milli korts og lesara er sérstakur hluti samþættingarinnar. Sjá yfirlit Open Charge Alliance yfir samskiptareglur.

Úthlutaðu einum einstaklingi ábyrgð á hverju lagi. Kortabirgir getur afhent samþykkt efnislegt auðkenni og auðkennisskrá; samþættingaraðili staðfestir hegðun lesara; rekstraraðili hleðslukerfisins stýrir reikningsskráningu og heimildum. Skráðu hver leysir úr ósamræmi áður en gangsetning hefst.

1. Staðfestu getu lesara og heimildaveitingar

Óskaðu eftir lesaralýsingu fyrir nákvæmlega þá gerð hleðslustöðvar, vélbúnaðarútgáfu og uppsettan fastbúnað sem á að nota. Skráðu hvaða snertilausu staðla lesarinn styður, hvaða auðkenningarham hann notar og hvort hægt sé að stilla umbreytingu auðkennisgilda. Lýsing á borð við „RFID-virkt“ svarar ekki þessum spurningum.

NFC notar 13.56 MHz og nær yfir nokkrar snertilausar tæknilausnir, þar á meðal ISO/IEC 14443 Type A, Type B og ISO/IEC 15693. Samsvörun tíðni ein og sér er því ófullnægjandi innkaupalýsing. Samræmdu raunverulega kortatækni og útfærslu lesarans. Tækniyfirlit NFC Forum útskýrir þessar undirliggjandi samskiptareglur.

Staðfestu síðan hvað stöðin og bakendinn útfæra í raun:

Skoða þarf OCPP-vottun eftir einstökum eiginleikum. Í uppfærslu OCA frá desember 2025 er Local List Management meðal valfrjálsra eiginleika OCPP 2.0.1 Core-sniðsins. Uppfærða vottunarkerfið tryggir því ekki að allar vottaðar stöðvar styðji staðbundna lista. Leiðbeiningar OCA um OCPP 2.Lite, kafli C, útskýra einnig að sleppa megi heimildaskyndiminni og að útfærslur geti stutt mismunandi heimildaveitingaraðferðir.

Óskaðu eftir umfangi vottunar og Protocol Implementation Conformance Statement, þar sem það er tiltækt, og berðu saman við uppsettan hugbúnað. Varðveittu gögnin með stillingum staðarins.

OCA gefur nú út pakka fyrir OCPP 1.6, 2.0.1 og 2.1. Dæmin hér að neðan eiga sérstaklega við 1.6 og 2.0.1; notaðu samsvarandi staðallýsingu fyrir 2.1-uppsetningu. Athugaðu opinbera niðurhalspakka og leiðréttingar við gangsetningu eða uppfærslu.

2. Skráðu auðkennisgildið frá raunverulegri hleðslustöð

Byrjaðu með lítið safn prófunarkorta sem hægt er að aðgreina. Haltu prentuðu kortatilvísuninni aðskildri frá rafræna gildinu: sýnilegt raðnúmer eins og CRF-TEST-0042 nýtist við aðstoð, en skrá þarf tengsl þess við auðkennisgildið í bakendanum.

Þetta eru skýringardæmi um gagnahluta heimildabeiðni í netsambandi með OCPP og tilbúnu auðkennisgildi:

OCPP 1.6

{"idTag":"04A1B2C3D4E5F7"}

OCPP 2.0.1

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

Dæmin sleppa umgjörð WebSocket-skilaboða. Opinber gagnaskemu tilgreina að hámarki 20 stafi fyrir idTag í 1.6 og 36 fyrir idToken-strenginn í 2.0.1; 2.0.1 krefst einnig tegundar auðkennistákns. Sannprófaðu gagnvart OCPP 1.6-pakkanum eða OCPP 2.0.1 Edition 4-pakkanum sem samþættingin notar.

Ræsing með staðbundinni heimild getur fylgt annarri skilaboðaröð. Láttu samþættingaraðilann sýna hvar auðkennið og heimildarákvörðunin eru skráð í þeim ham.

3. Semdu um framsetningu UID áður en kort eru flutt inn

Fyrir ISO14443-auðkennistákn mælir OCPP 2.0.1 með UID-bætum á sextándakerfissniði, með bæti 0 fyrst. Samt þarf að athuga hegðun eldri vara: OCPP-virkjunarleiðbeiningar Wallbox tilgreina sextándakerfisgildi í little-endian-röð án aðgreina fyrir þær vörur sem leiðbeiningarnar ná til. Þetta eru vörusértæk fyrirmæli, ekki almenn umbreytingarregla. Sjá OCPP 2.0.1, heimildakafla C.1.1 og virkjunarleiðbeiningar Wallbox, blaðsíður 14 og 20.

Fyrir þessa tilbúnu sjö bæta runu eru framsetningarnar:

Taflan sýnir umbreytingar, ekki fjögur gildi sem má nota á víxl í bakenda. Flyttu inn þá framsetningu sem samþættingin krefst. Viðsnúningur bæta breytir röð stafapara; viðsnúningur einstakra stafa gefur aðra niðurstöðu.

Skráðu vörpun milli birgisgagna, stöðvarannáls og innflutningsreits bakenda. Taktu með bætalengd, sextánda- eða tugakerfisframsetningu, bætaröð, aðgreina og allar sérstaklega skjalfestar umbreytingar. Varðveittu óunnu upprunaskrána. Forðastu óskjalfesta styttingu eða ágiskanir um bæti sem vantar.

Athugaðu hvort tækið hafi stillingar sem umbreyta auðkennisgildum. Wallbox eM4 WebAdmin-handbókin inniheldur til dæmis valkostinn „Shorten UIDs“ og varar við að breyta megi heimildastillingum bæði í staðbundna viðmótinu og bakendanum. Sjá Wallbox WebAdmin-handbókina, blaðsíðu 23. Skráðu virkar stillingar eftir að bæði kerfin hafa tengst.

Flyttu dálka með auðkennisgildum inn í töflureikna sem texta. Excel getur fjarlægt núll fremst og takmarkar tölunákvæmni við 15 marktæka tölustafi; tugakerfisdæmið okkar hefur 16 tölustafi. Að breyta birtingarsniði eftir að gögn hafa breyst endurheimtir ekki upprunalega auðkennisgildið. Fylgdu leiðbeiningum Microsoft um varðveislu auðkennisgagna.

Notaðu UID-umbreytinn frá ChargeRFID til að skoða framsetningar og tólið til afstemmingar auðkennisskráa til að bera saman framleiðslu- og bakendaskrár. Staðfestu fyrirhugaða vörpun gagnvart raunverulegum stöðvarannál áður en hún er notuð á lotuna.

4. Skráðu auðkenni og úthlutaðu viðskiptatengdum heimildum

Stofnaðu auðkennisfærsluna með skjalfestu skráningar- eða innflutningsferli kerfisins. Tengdu hana við fyrirhugaðan ökumann, ökutæki, deild eða viðskiptareikning eftir því hvernig reksturinn úthlutar hleðslu.

Skráðu eftirfarandi fyrir hvert auðkenni í tilrauninni:

Haltu þessu sem aðskildum samþykktaratriðum. Auðkenni getur verið í gagnagrunni án fyrirhugaðrar staðarheimildar eða reikningstengingar. Á sama hátt staðfestir vel heppnuð ræsing ekki að rétt reikningafyrirkomulag hafi verið notað.

Notaðu skráningarskrá með lotutilvísun, innflutningsniðurstöðu, fráviksástæðu og yfirlesara. Leystu úr tvíteknum gildum og ósamrýmanlegum úthlutunum áður en afhending hefst. Aðlagaðu UID-afhendingarsniðmátið að raunverulegum innflutningsskilmálum kerfisins; dæmilínan er prófunargögn.

Fyrir sameiginleg ökutæki þarf að semja um hver má stöðva lotu. Prófunartilvik OCA fyrir OCPP 1.6 ná sérstaklega til stöðvunar með kortinu sem hóf lotuna og stöðvunar með öðru korti sem tengist með samsvarandi yfirauðkenni. Prófaðu þá hóphegðun sem á að virkja. Sjá OCTT 2026-02-prófunartilvikin, kafla 2.3.1 og 2.3.2.

5. Settu skýrar reglur um ótengdan aðgang

Ákveddu hvort hleðsla eigi að vera möguleg þegar stöðin nær ekki í stjórnunarkerfið. Fyrir aðgangstakmarkaða bækistöð bílaflota er skynsamlegt upphaf að heimila fyrirhuguð, staðbundið samþykkt auðkenni og hafna óþekktum kortum meðan samband er rofið. Staðfestu að búnaðurinn geti framfylgt reglunum áður en treyst er á þær.

Heimildaskyndiminni geymir heimildaupplýsingar sem fengust í fyrri samskiptum. Staðbundnum heimildalista er stýrt og hann samstilltur frá bakenda. Þetta eru aðskildar leiðir. Að tæma annað staðfestir ekki að hitt hafi verið uppfært. OCPP 1.6 lýsir sambandi þeirra í kafla 3.5 í staðallýsingunni.

Þetta eru dæmi um útgáfusértæk heiti til að ræða við samþættingaraðila, ekki stillingaskrá til að líma í hleðslustöð:

Heitin staðfesta ekki að allir eiginleikar séu útfærðir, virkir eða breytanlegir. OCPP 2.0.1 notar vistfangagerð fyrir íhluti og breytur; tækjalíkanið og viðeigandi notkunartilvik ákvarða hvernig hver stilling virkar. Sjá kafla Edition 4 um heimildaveitingu og tilvísaðar breytur.

Skráðu rúmtak staðbundna listans, kvittun uppfærslna, meðferð gildisloka, varðveislu eftir endurræsingu og hegðun þegar geymsla fyllist. Prófaðu bæði þekkt auðkenni sem aldrei hefur verið notað á stöðinni og auðkenni sem þegar hefur fengið heimild þar. Þetta hjálpar til við að staðfesta á hvaða staðbundnu leið uppsetningin byggir í raun.

Taktu endurtengingu með í prófunina. Athugaðu hvernig ótengdar færslur berast bakenda og eru afstemmdar og hvað gerist með virka lotu ef bakendinn hafnar auðkenninu eftir að samband kemst á aftur. Semdu við eiganda staðarins um ásættanlega rekstrarlega og fjárhagslega áhættu.

6. Veldu öryggislíkan auðkennisins meðvitað

Spyrðu hvort lesarinn lesi aðeins auðkennisgildi eða framkvæmi dulritunarlega sannvottun með auðkenninu. Í hönnun sem byggir eingöngu á UID sýnir samþykki samsvarandi auðkennisgildis ekki fram á vörslu dulritunarlegs leyndarmáls. Kaup á flögu með öryggiseiginleikum skila aðeins gildi ef uppsettur lesari og forrit nýta þá.

Þegar dulritunarleg sannvottun korts er nauðsynleg skal skrá studda forritið, eignarhald lykla, undirbúnings- og stillingarferlið, útskiptiferlið og ábyrgð á flutningi milli kerfa. Haltu leyndarmálum utan UID-afhendingarskráa. RFID-öryggisleiðbeiningar NIST, kafli 5.3.1, lýsa muninum á auðkennisgildum og sannvottunarvörnum. Þetta eru grunnleiðbeiningar frá 2007; notaðu nýjustu vörugögn til að velja studd reiknirit og lyklastjórnunarleiðir.

Tryggðu öryggi tengingar stöðvar og bakenda sérstaklega. Núgildandi Security Operations Guide OCA, kaflar 4.2 og 4.4, lýsir Security Profile 2 sem TLS með Basic Authentication og Profile 3 sem TLS með biðlaravottorðum og fjallar um geymslu auðkenningarupplýsinga. Staðfestu flutningssniðið sem er í notkun, sannprófun vottorða og stjórnun auðkenningarupplýsinga stöðvarinnar. Þessar stillingar verja aðra tengingu en samband korts og lesara.

7. Bættu við reikiheimildum þegar þjónustan krefst þess

Einkauppsetning á vinnustað þarf hugsanlega aðeins auðkennisskrá eigin kerfis. Reiki bætir við öðrum skilum: rekstraraðili hleðslustöðva, eða CPO, þarf að fá heimild frá viðeigandi veitanda þjónustu fyrir rafknúnar samgöngur, eða eMSP, í gegnum studda samþættingu og viðskiptasamning.

Í OCPI 2.3.0 inniheldur auðkennistáknsfærsla lands- og aðilaauðkenni þjónustuveitandans sem á hana ásamt UID, tegund, gildi og reglum um leyfislista. Reglan ALLOWED_OFFLINE varðar samskipti CPO og eMSP. Að hleðslustöð missi samband við CSMS er sérstakt sambandsslit. Prófaðu bæði skilin ef þau eru bæði til staðar.

Tokens-einingin greinir einnig milli gilds auðkennistákns og tákns sem er leyft á tilteknum stað. Ógildingu er dreift með uppfærðu tákni með valid: false; eyðing tákna um þetta viðmót er ekki leiðin. Berðu opinberu OCPI 2.3.0 Tokens-eininguna saman við útgáfuna sem samið er um við samstarfsaðila.

Tilgreindu útgefanda og þátttökunet í tilrauninni, staðfestu fyrirhugaða heimildaleið og athugaðu lotuna og hleðslufærsluna sem verða til. Endurnýting sama efnislega kortsins milli þjónusta krefst enn réttrar skráningar, heimilda og samninga.

8. Taktu allan aðgangsferilinn í notkun

Notaðu prófunarfylki með væntum niðurstöðum sem eru skráðar fyrir prófun. Keyrðu það á hverri sérstakri samsetningu vélbúnaðar, fastbúnaðar og bakenda og taktu síðan stikkprufur af uppsettum búnaði gagnvart samþykktri uppsetningu.

Varðveittu tíma, auðkenni stöðvar og tengis, fastbúnað, prófunarkortstilvísun, virkar stillingar, vænta niðurstöðu, raunverulega niðurstöðu og viðeigandi færslu fyrir hverja keyrslu. Afmáðu persónuupplýsingar í gögnum sem deilt er utan rekstrarteymisins.

Þegar kort týnist skal skrá hvenær tilkynning barst og hvenær hvert tengt kerfi staðfesti breytinguna. Ótengd stöð getur ekki tekið við nýrri afturköllun samstundis. Raunveruleg áhætta ræðst af geymdri heimildastöðu, gildisreglum og hegðun við endurtengingu. Taktu á þessu tímabili í rekstrarferlinu.

Greindu misheppnaðan kortalestur við rétt skil

Safnaðu einni misheppnaðri tilraun með tímastimpli og kortatilvísun og farðu síðan yfir gögnin. Þessar athuganir afmarka rannsóknina án þess að gera ráð fyrir að allar hafnanir eigi sér sömu orsök.

Dæmi um innleiðingu á bækistöð bílaflota

Hugsum okkur tilbúna bækistöð með 60 ökumönnum, 12 hleðslustöðum og tveimur gerðum hleðslustöðva. Rekstraraðilinn vill tengja aðgang við einstaka ökumenn, takmarka hann við bækistöðina og leyfa samþykktum ökumönnum að hlaða þegar bakendinn er óaðgengilegur.

Byrjaðu með fimm prufuauðkenni. Skráðu tilkynnt auðkennisgildi á hvorri gerð hleðslustöðvar og semdu um vörpun í birgisskrá. Skráðu sýnin á tilraunareikning, úthlutaðu aðgangi að bækistöðinni og staðfestu fyrirhugaðan kostnaðarstað.

Ef búnaðurinn styður stýrðan staðbundinn lista skaltu hlaða prufuauðkennunum inn fyrirfram og skrá staðfesta útgáfu. Haltu aðgangi óþekktra auðkenna án nets óvirkum samkvæmt þessum fyrirhuguðu reglum. Aftengdu stöðina frá CSMS í stýrðri prófun og prófaðu síðan fyrirfram innlesið kort, óþekkt kort og afturkallað kort með viljandi skjalfestri úreltri staðbundinni stöðu. Endurheimtu sambandið og sannprófaðu uppfærslu- og færslugögn.

Ljúktu prófunum á höfnun í netsambandi, stöðvun lotu og reikningagerð á báðum gerðum. Þegar tilraunin hefur staðist skaltu afstemma framleiðsluskrána með 60 kortum við bakendaskrána, leysa úr frávikum og afhenda kortin með einföldu ferli fyrir tilkynningar um týnd kort. Endurtaktu viðeigandi samþykktarprófanir eftir verulegar breytingar á fastbúnaði, lesaraham eða kerfi.

Spurningar sem þarf að leysa fyrir pöntun

Þarf að forrita RFID-hleðslukort?

Í hönnun sem les núverandi UID kortsins getur uppsetning falist í skráningu gildisins og úthlutun aðgangs í kerfinu. Hönnun með vernduðu forriti getur krafist sérstillingar korta og samræmdra lesarastillinga. Tilgreindu nákvæmt lesaraferli áður en hvor þjónustan um sig er pöntuð.

Getur núverandi starfsmannakort einnig opnað aðgang að hleðslustöð?

Það getur verið mögulegt ef lesarinn styður tækni kortsins, nauðsynlegt auðkennisgildi er tiltækt og stöðugt og kerfið leyfir skráningu. Fáðu samþykki eiganda kortakerfisins og prófaðu raunveruleg sýnishorn. Sem dæmi um kerfissértæka skráningu lýsa leiðbeiningar Easee um reikninga og staðbundna lykla mismunandi skráningarumfangi og vara við breytilegum auðkennisgildum.

Virkar eitt kort á öllum hleðslunetum?

Staðfestu hvert fyrirhugað net sérstaklega. Efnislegur læsileiki, skráning auðkennis, reikningsheimildir og hugsanlegur reikisamningur eru allt hluti samþykktarskilyrðanna. Prófaðu netið sem tekur þátt í stað þess að álykta um aðgang út frá útliti kortsins.

Hvað ætti kortabirgirinn að fá?

Afhentu lesarakröfur, samþykkta vörpun sýnisauðkenna, sýnilegt númerakerfi, efnis- og prentlýsingu, magn og samþykkt gagnaafhendingarsnið. Tilgreindu ábyrgðarmann innflutnings í bakenda og samþykktar sýnishorna. Flyttu leyndarmál forritsins með sérstöku öruggu undirbúningsferli sem samið er um ef hönnunin krefst þeirra.

Undirbúðu sýnishornalýsingu fyrir uppsetninguna

Sameinaðu gerð og fastbúnað hleðslustöðvar, heiti bakenda og útgáfu samskiptareglu, nauðsynlegan auðkenningarham, staðfesta auðkennisframsetningu og fyrirhugaðar reglur um ótengda notkun í eina lýsingu. Notaðu auðkennistilraunastofu ChargeRFID til að yfirfara gagnaafhendinguna og óskaðu eftir fullbúnum sýnishornum fyrir tilraunina. Samþykktu efnislega auðkennið og allt aðgangsferlið saman áður en framleiðslupöntunin er heimiluð.