OCMF yra atviras matavimo duomenų mainų standartas, specialiai sukurtas elektromobilių įkrovimui. Dėl standartizuotos struktūros, šifruotų parašų ir lanksčios adaptacijos jis sprendžia tris pagrindinius pramonės problemų klausimus: skaidrumo trūkumą apmokestinimo matavimuose, jautrumą duomenų klastojimui ir protokolų nesuderinamumą. Dėl to sąskaitų apmokestinimas tampa patikimesnis, o pramonės bendradarbiavimas – efektyvesnis.
Kas yra OCMF?
OCMF (Open Charge Metering Format) yra pramonės standartas, reklamuojamas Europos įkrovimo aljanso ir SAFE{0}}eV organizacijos. Tai tarsi „bendroji kalba“, skirta apskaitos duomenims įkrovimo pramonėje, apibrėžianti vieningas įkrovimo duomenų perdavimo tarp įkrovimo stotelių, valdymo sistemų ir operatorių taisykles. Taip užtikrinama, kad pagrindinė informacija, pvz., įkrovimo suma, įkrovimo laikas ir kaina, būtų „suprantama, skaitoma ir apsaugota nuo klastojimo“.
Paprasčiau tariant, prieš OCMF skirtingų markių įkrovimo stotys naudojo skirtingus duomenų formatus, pavyzdžiui, skirtinguose regionuose buvo kalbama skirtingais dialektais, todėl tiesioginis ryšys buvo neįmanomas. Naudojant OCMF, visi suderinami įrenginiai naudoja vieningą „kalbą“ duomenims perduoti, užtikrinant, kad duomenys būtų atsekami ir patikrinami nuo įkrovimo pradžios iki sąskaitos užbaigimo.
Pagrindiniai OCMF technologiniai akcentai
1. Standartizuota struktūra: „Duomenų silosų“ suskaidymas OCMF yra lengvas dizainas be sudėtingų papildomų antraščių. Pagrindiniai duomenys yra įterpti į fiksuotą formatą, prisitaikant prie įprastų nuoseklaus ryšio scenarijų, tokių kaip RS-485. Tai apima pagrindinius laukus, tokius kaip įkrovimo suma (Wh), įkrovimo laikas, įrenginio ID ir tarifo informacija, taip pat palaiko versijos iteraciją ir plėtrą – pavyzdžiui, V1.2.0 pridėjo kabelio nuostolių kompensavimo duomenis, o V1.3.0 – įkrovimo krūvos valdiklio programinės aparatinės įrangos versijos lauką, užtikrinantį vienodumą ir lankstumą. Šis standartizavimas leidžia skirtingų prekių ženklų įkrovimo krūvoms, valdymo platformoms (CSMS) ir mokėjimo sistemoms veikti be papildomo pritaikymo, o tai žymiai sumažina pramonės bendradarbiavimo išlaidas.
2. Šifravimo ir parašo mechanizmas: „Duomenų klastojimo“ pašalinimas Tai yra svarbiausias OCMF saugumo dizainas. Įkrovimo krūvos sugeneruoti matavimo duomenys yra užšifruojami ir pasirašomi prieš perduodant, o gavėjas patikrina duomenų vientisumą naudodamas viešąjį raktą. Tai tarsi „saugos vandens ženklo“ pridėjimas prie duomenų; jei jis bus sugadintas, patvirtinimo procesas nedelsdamas jį aptiks, kad būtų išvengta „permokėjimo ir neteisingo atsiskaitymo“ problemų šaltinyje.
Šis mechanizmas visiškai atitinka tarptautinius metrologijos reglamentus, pvz., German Mess{0}} & Eichrecht, todėl apmokestinimo duomenys yra teisiškai galiojantys ir naudotojų, operatorių ir reguliavimo institucijų pasitikėjimo pagrindas.
3. Kelių{1}}protokolių pritaikymas: suderinamas su naujais ir senais įrenginiais OCMF neapsiriboja vienu ryšio protokolu ir gali lanksčiai prisitaikyti prie pagrindinių įkrovimo protokolų, pvz., OCPP 1.6 ir OCPP 2.0.1/2.1. Konfigūruodamas skirtingus parametrus, jis gali palaikyti tradicinius fiksuoto įkrovimo scenarijus ir patenkinti naujus poreikius, pvz., ad hoc įkrovimą. Pavyzdžiui, OCPP 2.0.1 sistemoje, įjungus atitinkamą konfigūraciją, OCMF gali automatiškai perduoti pasirašytus duomenis pagrindiniuose mazguose, tokiuose kaip įkrovimo pradžia ir pabaiga, nekeičiant esamos aparatinės įrangos, todėl senesnius įrenginius galima atnaujinti į „patikimus matavimo įrenginius“.
Praktiniai OCMF pritaikymai
1. Taikymo scenarijai apima visą apmokestinimo ekosistemą:
● Įkrovimo polių gamintojai: projektuoja apskaitos modulius pagal OCMF standartus, leidžiančius tiesiogiai integruoti duomenis su pagrindinėmis operatorių platformomis be atskiro pritaikymo.
● Įkrovimo operatoriai: vienodai gaukite duomenis iš įvairių markių įkrovimo polių, supaprastindami vidinį valdymą ir sumažindami eksploatavimo bei priežiūros išlaidas.
● Naudotojai: po apmokestinimo naudotojai gali patikrinti atsiskaitymo duomenų autentiškumą naudodami šifruotus parašus, taip išvengdami ginčų dėl „per didelių apmokestinimo mokesčių“.
● Reguliavimo agentūros: tiesiogiai pasiekite suderinamus matavimo duomenis, įgalindami ne{0}}svetainės priežiūrą ir pagerindami pramonės valdymo efektyvumą.
2. Tipinė darbo eiga
● Norėdami pradėti krauti, įkišate įkrovimo laidą, o įkrovimo stotelė realiu laiku įrašo tokius duomenis kaip įkrovimo kiekis ir laikas;
● Duomenys įterpiami į OCMF formatą, o „skaitmeninis parašas“ generuojamas naudojant šifravimo algoritmą;
● Pasirašytas OCMF duomenų paketas SLIP protokolu perduodamas valdymo platformai (su pradžios ir pabaigos skyrikliais);
● Po to, kai platforma patikrina parašą, ji analizuoja duomenis ir sugeneruoja sąskaitą;
● Baigus įkrauti, visą OCMF duomenų įrašą galima naudoti kaip atsiskaitymo kvitą, kad būtų galima atlikti tolesnį patikrinimą.
OCMF versijos raida
Nuolat tobulinamas pramonės standartas OCMF nuo pat jo pasirodymo buvo nuolatos kartojamas, prisitaikant prie esamų pramonės poreikių: V1.0.1: Išaiškintas versijos apibrėžimas ir pagrindinė duomenų struktūra, padedanti standartizacijos pagrindus;
● V1.1.0: pridėta informacija apie tarifus, kad būtų galima prisitaikyti prie laikino apmokestinimo scenarijų;
● V1.2.0: pridėti kabelio nuostolių kompensavimo duomenys, siekiant išspręsti energijos praradimo įkrovimo metu matavimo problemas;
● V1.3.0: pridėtas valdiklio programinės aparatinės įrangos versijos laukas, siekiant pagerinti įrenginio valdymo tikslumą.
Kiekvienas atnaujinimas yra susijęs su „didesnio tikslumo, didesnio saugumo ir didesnio suderinamumo“ tikslais, užtikrinant, kad standartas visada žengtų koja kojon su pramonės plėtra.
OCMF pagrindinių laukų ir taikymo scenarijų nuorodų lentelė
Šioje nuorodų lentelėje apibendrinami pagrindiniai OCMF (Open Charging Measurement Format) versijų V1.0.1–V1.3.0 laukai, paaiškinama kiekvieno lauko reikšmė, duomenų tipas, versijos palaikymas ir pagrindiniai programos scenarijai. Tai palengvina greitą nuorodą ir praktinį diegimo pritaikymą.
| Lauko pavadinimas | Lauko reikšmė | Duomenų tipas | Versijos palaikymas | Pagrindiniai taikymo scenarijai |
|---|---|---|---|---|
| ver | OCMF formato versijos numeris | Eilutė (pvz., „1.3.0“) | Visos versijos | Versijos pritaikymui tarp įrenginio ir platformos, užtikrinant duomenų analizavimo suderinamumą |
| gw_vendor | Šliuzo tiekėjo identifikatorius | Styga | V0.4 ir naujesnės versijos | Prietaiso atsekamumas; atskirti šliuzus nuo skirtingų tiekėjų, skirtus eksploatavimo ir priežiūros valdymui |
| gw_sn | Vartų serijos numeris | Eilutė (būtina) | V0.4 ir naujesnės versijos | Unikaliai identifikuoti šliuzo įrenginius; sudaryti sekamą grandinę su matavimo duomenimis |
| matuoklis_pardavėjas | Matavimo modulio tiekėjo ID | Styga | Visos versijos | Apskaitos prietaisų atsekamumas; nustatyti atsakingus subjektus ginčų dėl duomenų atveju |
| meter_sn | Matavimo modulio serijos numeris | Eilutė (būtina) | Visos versijos | Unikaliai identifikuoti matavimo modulius; užtikrinti matavimo duomenų ir įrenginių atitikimą vienas{0}}prie- |
| energijos | Bendra įkrovimo energija | Skaitinis (vienetas: Wh) | Visos versijos | Pagrindinis atsiskaitymo pagrindas; pagrindiniai vartotojo atsiskaitymo ir operatoriaus suderinimo duomenys |
| pradžios_laikas | Įkrovimo pradžios laikas | Laiko žyma | Visos versijos | Apskaičiuokite įkrovimo trukmę, suderinkite{0}}laikotarpio elektros kainas ir sugeneruokite tikslias sąskaitas |
| pabaigos_laikas | Įkrovimo pabaigos laikas | Laiko žyma | Visos versijos | Patvirtinkite įkrovimo ciklą; apskaičiuokite bendrą įkrovimo trukmę su pradžios laiku |
| tarifas | Informacija apie elektros kainą (įskaitant laikotarpius, įkainius) | Struktūrizuoti duomenys | 1.1.0 ir naujesnės versijos | Prisitaikyti prie laikino įkrovimo scenarijų; palaikymo laikas-naudojant-kainodarą ir dinaminį tarifų atsiskaitymą |
| kabelio praradimas | Kabelio nuostolių kompensavimo energija | Skaitinis (vienetas: Wh) | 1.2.0 ir naujesnės versijos | Teisingas energijos praradimas įkrovimo metu; užtikrinti matavimo duomenų tikslumą |
| plg | Įkrovimo polių valdiklio programinės įrangos versija | Eilutė (neprivaloma) | 1.3.0 ir naujesnės versijos | Programinės įrangos valdymas; nustatyti, ar reikia atnaujinti matavimo spragas |
| parašas | Skaitmeninis parašas | Šifruota eilutė | Visos versijos | Duomenų apsaugos nuo padirbinėjimo{0}}patikrinimas; užkirsti kelią atsiskaitymo duomenų klastojimui ir užtikrinti teisinį galiojimą |
| sig_alg | Parašo algoritmo identifikatorius | Styga | V0.4 ir naujesnės versijos | Išaiškinti duomenų šifravimo metodą; imtuvas patikrina parašą atitinkamu algoritmu |
| auth_status | Prieigos būsena (pavyko ar ne) | Būlio | V0.4 ir naujesnės versijos | Patvirtinti apmokestinimo operacijų teisėtumą; atmesti atsiskaitymą už neteisėtas operacijas |
| įvykių_skaitiklis | Renginių skaitiklis | Sveikasis skaičius | V0.4 ir naujesnės versijos | Įrašykite pagrindinių įvykių skaičių įkrovimo metu; padėti šalinant gedimus |
Papildomos pastabos dėl lauko prioriteto:
1. Laukai, pažymėti kaip "būtini" (pvz., gw_sn, meter_sn, energy), yra esminiai matavimo duomenų galiojimui; jų nebuvimas trukdys normaliai atsiskaityti.
2. Versijų suderinamumas: žemesnės versijos sistemose laukai iš aukštesnių versijų (pvz., cable_loss, cf) yra neprivalomi. Jei reikia šių laukų, įrenginį reikia atnaujinti į atitinkamą versiją.
3. Protokolo pritaikymas: visi laukai gali būti perduodami naudojant OCPP 1.6 ir OCPP 2.0.1/2.1 protokolus, nereikalaujant jokių papildomų lauko struktūros pakeitimų.
OCMF lauko ir OCPP protokolo suderinamumo atvaizdavimo lentelė
OCMF, kaip įkrovimo matavimo duomenų standartas, duomenų perdavimui tarp įrenginių remiasi OCPP (Open Charge Point Protocol). Toliau pateiktoje lentelėje paaiškinama perdavimo terpė, konfigūracijos priklausomybės ir pagrindinių OCMF laukų pritaikymo taisyklės skirtingose OCPP versijose, sprendžiant praktinį klausimą „kaip OCMF duomenys perduodami ir sėkmingai perduodami OCPP“.
| OCMF pagrindinis laukas | Lauko reikšmė | Palaikoma OCPP versija | OCPP perdavimo nešiklis (pranešimas / laukas) | OCPP konfigūracijos priklausomybė |
|---|---|---|---|---|
| FV | OCMF formato versija (pvz., 1.0, 1.2.0) | 1.5 ir daugiau | „SignedData“ metaduomenys (įterpti į „MeterValue“ atributus) | Nereikia papildomos konfigūracijos |
| GS | Šliuzo serijos numeris (unikalus parašo komponentų identifikatorius) | 1.5 ir daugiau |
1. MeterValue.req → JSON programoje SignedData 2. StopTransaction.req → TransactionData |
Konfigūruoti „šliuzo{0}}įkrovimo krūvos susiejimo ryšį“ (pvz., susieti GS su OCPP ChargePointIdentity) |
| MS | Matavimo modulio serijos numeris (unikalus skaitiklio identifikatorius) | 1.5 ir daugiau | JSON sistemoje „SignedData“ (sugrupuota su MV/MF kaip „matavimo įrenginio informacija“) | Jokios papildomos konfigūracijos, tačiau įsitikinkite, kad MS yra susieta su įkrovimo krūvos profiliais OCPP vidinėje programoje |
| RD-TM | Skaitymo laikas (įskaitant sinchronizavimo būseną, pvz., „2018-07-24T13:22:04, 000+0200 S“) | 1.5 ir daugiau |
1. MeterValue.timestamp (bazinis laikas) 2. JSON sistemoje „SignedData“ (sinchronizavimo būsena „S/R“) |
Konfigūruoti ClockAlignedDataInterval{0}} (15 minučių, suderinama su matavimo reguliavimo laiko tarpsniais) |
| RD-RV | Skaitiklio rodmuo (pvz., 2935,6 kWh) | 1.5 ir daugiau |
1. MeterValue.value (neapdorotas formatas, skirtas greitai pateikti) 2. JSON „SignedData“ (pasirašytas formatas, skirtas atsiskaitymo patvirtinimui) |
Konfigūruoti MeterValue.sAlignedData=Active.Energy.Register.Import |
| RD-TX | Operacijos būsena (pvz., B=Pradžia, E=Pabaiga, T=Tarifo pakeitimas) | 1.5 ir daugiau |
1. StartTransaction.req → TransactionStatus 2. StopTransaction.req → Priežastis 3. MeterValue.req → JSON programoje SignedData |
Sukonfigūruoti StopTransactionsSignatureFormat=MR/SR (MR: vienas pradžios / sustabdymo duomenų perdavimas; SR: du atskiri perdavimai) |
| LC | Kabelio nuostolių kompensavimas (įskaitant LR varžą, LU bloką ir kt.) | 2.0 ir naujesnės versijos | JSON sistemoje „SignedData“ (naujas OCMF 1.2.0 laukas) | Atnaujinti OCPP protokolą į 2.0+; įkrovimo krūvos valdiklyje sukonfigūruokite "kabelio praradimo algoritmo parametrus". |
| YRA | Naudotojo prieigos būsena (teisinga=Įgaliota, klaidinga=Neteisėta) | 2.0 ir naujesnės versijos |
1. Authorize.req → IdTagInfo.Status 2. JSON sistemoje „SignedData“ (yra susieta su OCPP prieigos teisės rezultatu) |
Konfigūruoti OCPP_AUTH_TLS (autorizuoti duomenis naudojant TLS šifruotą tekstą) |
| IT | Naudotojo identifikavimo tipas (pvz., ISO14443=RFID kortelė) | 2.0 ir naujesnės versijos | Authorize.req → IdTagType (arba JSON sistemoje „SignedData“) | Sukonfigūruokite „identifikavimo tipo ir IdTag susiejimą“ OCPP vidinėje programoje (pvz., ISO14443 atitinka OCPP IdTag 16 skaitmenų šešioliktainiu formatu) |
| SD | Skaitmeninio parašo duomenys (ECDSA šifravimo rezultatas) | 1.5 ir daugiau |
1. MeterValue.req → Reikšmė (ValueFormat=SignedData, užkoduota šešioliktaine forma) 2. StopTransaction.req → TransactionSignature |
1. Sukonfigūruokite SignatureAlgorithm=ECDSA-secp256r1-SHA256 (numatytasis OCMF algoritmas) 2. Įgalinkite MeterValuesSignatureContext=CSL/RW (nurodyti parašo suaktyvinimo taškus) |
| PG | Puslapio identifikatorius (pvz., 12345 operacijos T12345=skaitymas) | 1.5 ir daugiau | JSON sistemoje „SignedData“ (susieta su OCPP TransactionId) | Sukonfigūruokite puslapių tęstinumo patikrą (OCPP backend patikrina nuoseklius PG numerius, pvz., T1 → T2 → T3, kad būtų išvengta duomenų praradimo) |
Papildomos pastabos
1. Vieningo perdavimo formato taisyklės: visi OCMF laukai yra įterpti į „SignedData“ formatą OCPP, ty OCMF|
2. Versijų suderinamumo ribos:
● OCPP 1.5: palaiko tik pagrindinius OCMF laukus (pvz., FV, GS, RD-RV, SD) ir nepalaiko aukštesnės versijos laukų (LC, IT ISO15118 tipo);
● OCPP 2.0 ir naujesnės versijos: visiškai palaiko visus OCMF 1.2.0 ir senesnės versijos laukus ir gali būti išplėstas, kad būtų galima pritaikyti būsimus OCMF papildymus lauke „CustomData“.
3. Konfigūracijos prioritetas: kai OCPP konfigūracija prieštarauja OCMF reikalavimams (pvz., OCPP ClockAlignedDataInterval ≠ 15 minučių), pirmenybė turi būti teikiama OCMF matavimo taisyklėms (pvz., priverstinai koreguojama iki 900 sekundžių), kad būtų užtikrinta, jog duomenys atitinka kalibravimo teisinį galiojimą.
Santrauka: Kodėl OCMF tampa esminiu standartu pramonėje?
Sparčiai besivystančioje elektromobilių įkrovimo pramonėje matavimo duomenų patikimumas ir sąveikumas yra pagrindinės kliūtys. OCMF derinys „vieningas formatas + šifruotas patvirtinimas + lankstus pritaikymas“ sprendžia pagrindinį naudotojo susirūpinimą dėl „sąžiningo atsiskaitymo“, sumažina techninio pritaikymo išlaidas įmonėms ir suteikia skaidrią reguliavimo įrankį, kad iš tikrųjų būtų naudinga visoms šalims.{3}}
Vis daugiau įkrovimo polių gamintojų ir operatorių priims OCMF standartą, todėl ateityje įkrovimo patirtis taps patogesnė – vartotojai galės drąsiai naudoti bet kokio prekės ženklo įkrovimo krūvą ir sklandžiai atsiskaityti skirtingose operatoriaus platformose. Tai yra pagrindinė vertybė, kurią pramonei suteikia atviri standartai.
