OCMF är en öppen standard för utbyte av mätdata, speciellt utformad för laddning av elfordon. Genom standardiserad struktur, krypterade signaturer och flexibel anpassning åtgärdar den tre stora smärtpunkter i branschen: bristande transparens i laddningsmätning, känslighet för datamanipulation och protokollinkompatibilitet. Detta gör debitering mer pålitlig och branschsamarbete mer effektivt.
Vad är OCMF?
OCMF (Open Charge Metering Format) är en industristandard som marknadsförs av European Charging Alliance och SAFE-eV-organisationen. Det är som det "vanliga språket" för mätdata i laddningsindustrin, som definierar enhetliga regler för överföring av laddningsdata mellan laddstationer, ledningssystem och operatörer. Detta säkerställer att nyckelinformation som laddningsbelopp, laddningstid och kostnad är "förståelig, läsbar och -säker".
Enkelt uttryckt, före OCMF, använde olika märken av laddstationer olika dataformat, som olika regioner som talar olika dialekter, vilket gjorde direkt kommunikation omöjlig. Med OCMF använder alla kompatibla enheter ett enhetligt "språk" för att överföra data, vilket säkerställer att data är spårbara och verifierbara från början av laddning till slutförande av fakturering.
Viktiga tekniska höjdpunkter hos OCMF
1. Standardiserad struktur: Brytning av "Data Silos" OCMF antar en lätt design utan komplexa extra rubriker. Kärndata är inkapslade i ett fast format, anpassat till vanliga seriella kommunikationsscenarier som RS-485. Den innehåller nyckelfält som laddningsbelopp (Wh), laddningstid, enhets-ID och tariffinformation, och stöder även versionsupprepning och expansion – till exempel V1.2.0 lade till data för kabelförlustkompensation och V1.3.0 lade till versionsfältet för laddningshögstyrenhetens firmware, vilket säkerställer både enhetlighet och flexibilitet. Denna standardisering gör att olika märken av laddningshögar, hanteringsplattformar (CSMS) och betalningssystem kan samverka utan ytterligare anpassning, vilket avsevärt minskar kostnaderna för industrisamarbete.
2. Kryptering och signaturmekanism: Eliminera "Datamanipulation" Detta är den mest avgörande säkerhetsdesignen för OCMF. Mätdata som genereras av laddningshögen krypteras och signeras före överföring, och mottagaren verifierar dataintegriteten med hjälp av en offentlig nyckel. Det är som att lägga till en "säkerhetsvattenstämpel" till data; om det manipuleras kommer verifieringsprocessen omedelbart att upptäcka det, vilket förhindrar problem med "överdebitering och felaktig fakturering" vid källan.
Denna mekanism överensstämmer helt med internationella metrologiföreskrifter som tyska Mess- och Eichrecht, vilket gör debiteringsdata juridiskt giltiga och ger en grund för förtroende för användare, operatörer och tillsynsmyndigheter.
3. Multi-Protokollanpassning: Kompatibel med "nya och gamla enheter" OCMF är inte begränsat till ett enda kommunikationsprotokoll och kan flexibelt anpassas till vanliga laddningsprotokoll som OCPP 1.6 och OCPP 2.0.1/2.1. Genom att konfigurera olika parametrar kan den stödja traditionella fasta laddningsscenarier och möta nya behov som ad-hoc-laddning. Till exempel, i ett OCPP 2.0.1-system, efter att ha aktiverat den relevanta konfigurationen, kan OCMF automatiskt överföra signerade data vid nyckelnoder såsom start och slut på laddning, utan att modifiera befintlig hårdvara, vilket gör att äldre enheter kan uppgraderas till "betrodda mätenheter".
Praktiska tillämpningar av OCMF
1. Applikationsscenarier täcker hela laddningsekosystemet:
● Tillverkare av laddhögar: Designa mätmoduler enligt OCMF-standarder, vilket möjliggör direkt dataintegration med större operatörsplattformar utan separat anpassning.
● Laddningsoperatörer: Ta enhetligt emot data från olika märken av laddningshögar, vilket förenklar backend-hanteringen och minskar drift- och underhållskostnaderna.
● Användare: Efter debitering kan användare verifiera äktheten av faktureringsdata genom krypterade signaturer, för att undvika tvister om "orimliga debiteringsavgifter".
● Tillsynsmyndigheter: Direkt åtkomst till kompatibla mätdata, vilket möjliggör övervakning utanför-webbplatsen och förbättrar effektiviteten i branschstyrningen.
2. Typiskt arbetsflöde
● Du kopplar in laddningskabeln för att börja ladda, och laddstationen registrerar data som laddningsmängd och tid i realtid;
● Datan är inkapslad i OCMF-format och en "digital signatur" genereras med hjälp av en krypteringsalgoritm;
● Det signerade OCMF-datapaketet överförs till hanteringsplattformen via SLIP-protokollet (med start- och slutavgränsare);
● Efter att plattformen har verifierat signaturen analyserar den data och genererar en faktura;
● När laddningen är klar kan hela OCMF-dataposten användas som en faktureringskupong för att stödja efterföljande verifiering.
OCMF Version Evolution
Den kontinuerligt förbättrade branschstandarden OCMF har genomgått ständiga iterationer sedan lanseringen, anpassad till faktiska industribehov: V1.0.1: Förtydligad versionsdefinition och grundläggande datastruktur, som lägger grunden för standardisering;
● V1.1.0: Tillagd tariffinformation för anpassning till tillfälliga debiteringsscenarier;
● V1.2.0: Lade till data för kabelförlustkompensation för att ta itu med mätutmaningarna med energiförlust under laddning;
● V1.3.0: Lade till fältet för version av controllerns firmware för att förbättra enhetshanteringens noggrannhet.
Varje uppdatering kretsar kring målen "större noggrannhet, större säkerhet och större kompatibilitet", vilket säkerställer att standarden alltid håller jämna steg med utvecklingen i branschen.
Referenstabell för OCMF-kärnfält och tillämpningsscenarier
Den här referenstabellen sammanfattar kärnfälten för OCMF (Open Charging Measurement Format) versioner V1.0.1 till V1.3.0, och klargör innebörden, datatypen, versionsstödet och kärnapplikationsscenarionerna för varje fält. Det underlättar snabb referens och praktisk implementeringsanpassning.
| Fältnamn | Fältets betydelse | Datatyp | Version Support | Kärnapplikationsscenarier |
|---|---|---|---|---|
| ver | OCMF-formatets versionsnummer | Sträng (t.ex. "1.3.0") | Alla versioner | För versionsanpassning mellan enhet och plattform, vilket säkerställer kompatibilitet med dataparsning |
| gw_vendor | Gateway-leverantörsidentifierare | Sträng | V0.4 och uppåt | Enhetens spårbarhet; särskilja gateways från olika leverantörer för drift- och underhållshantering |
| gw_sn | Gatewayens serienummer | Sträng (obligatoriskt) | V0.4 och uppåt | Identifiera gateway-enheter unikt; bilda en spårbar kedja med mätdata |
| meter_leverantör | Mätmodulens leverantörs-ID | Sträng | Alla versioner | Spårbarhet av mätanordningar; lokalisera ansvariga enheter i händelse av datatvister |
| meter_sn | Mätmodulens serienummer | Sträng (obligatoriskt) | Alla versioner | Identifiera mätmoduler unikt; säkerställ en-till-överensstämmelse mellan mätdata och enheter |
| energi | Total laddningsenergi | Numerisk (Enhet: Wh) | Alla versioner | Grundläggande fakturering; basdata för användaravräkning och operatörsavstämning |
| start_time | Starttid för laddning | Tidsstämpel | Alla versioner | Beräkna laddningslängd, matchningstids-elpriser och generera korrekta räkningar |
| sluttid | Sluttid för laddning | Tidsstämpel | Alla versioner | Bekräfta laddningscykeln; beräkna total laddningstid med starttid |
| taxa | Information om elpris (inklusive tidsperioder, priser) | Strukturerad data | V1.1.0 och högre | Anpassa till tillfälliga laddningsscenarier; supporttid-av-användningsprissättning och dynamisk tariffavräkning |
| kabelförlust | Kabelförlustkompensationsenergi | Numerisk (Enhet: Wh) | V1.2.0 och högre | Korrigera energiförlust under laddning; säkerställa mätdata noggrannhet |
| jfr | Firmwareversion för laddningshögkontroller | Sträng (valfritt) | V1.3.0 och högre | Firmwarehantering; avgöra om uppgraderingar behövs för att åtgärda mätningssårbarheter |
| signatur | Digital signatur | Krypterad sträng | Alla versioner | Verifiering av data mot-förfalskning; förhindra manipulering av faktureringsdata och säkerställa rättslig giltighet |
| sig_alg | Signaturalgoritmidentifierare | Sträng | V0.4 och uppåt | Förtydliga datakrypteringsmetod; mottagaren verifierar signaturen med motsvarande algoritm |
| auth_status | Auktoriseringsstatus (framgång eller inte) | Boolean | V0.4 och uppåt | Bekräfta legitimiteten för debiteringstransaktioner; avvisa betalning för obehöriga transaktioner |
| event_counter | Händelseräknare | Heltal | V0.4 och uppåt | Registrera antalet viktiga händelser under laddning; hjälpa till med felsökning |
Ytterligare anmärkningar om fältprioritet:
1. Fält markerade som "obligatoriskt" (såsom gw_sn, meter_sn, energi) är grundläggande för mätdatas giltighet; deras frånvaro kommer att förhindra normal avveckling.
2. Versionskompatibilitet: Fält från högre versioner (såsom cable_loss, cf) är valfria i system med lägre versioner. Uppgradering av enheten till motsvarande version krävs om dessa fält behövs.
3. Protokollanpassning: Alla fält kan överföras via protokollen OCPP 1.6 och OCPP 2.0.1/2.1 utan att det krävs några ytterligare modifieringar av fältstrukturen.
Tabell för OCMF-fält och OCPP-protokollkompatibilitet
OCMF, som en laddningsmätningsdatastandard, förlitar sig på OCPP (Open Charge Point Protocol) för dataöverföring mellan enheter. Tabellen nedan förtydligar överföringsmediet, konfigurationsberoendena och anpassningsreglerna för kärn-OCMF-fält i olika OCPP-versioner, och tar upp den praktiska frågan om "hur OCMF-data överförs och kommuniceras framgångsrikt inom OCPP."
| OCMF kärnfält | Fältets betydelse | OCPP-version som stöds | OCPP-överföringsbärare (meddelande/fält) | OCPP-konfigurationsberoende |
|---|---|---|---|---|
| FV | OCMF-formatversion (t.ex. 1.0, 1.2.0) | 1,5 och uppåt | SignedData-metadata (inbäddad i MeterValue-attribut) | Ingen ytterligare konfiguration krävs |
| GS | Gateways serienummer (unik identifierare för signaturkomponenter) | 1,5 och uppåt |
1. MeterValue.req → JSON i SignedData 2. StopTransaction.req → TransactionData |
Konfigurera "gateway-laddningshögbindningsrelation" (t.ex. associera GS med OCPP:s ChargePointIdentity) |
| MS | Mätmodulens serienummer (unik mätaridentifierare) | 1,5 och uppåt | JSON i SignedData (grupperad med MV/MF som "mätenhetsinformation") | Ingen ytterligare konfiguration, men se till att MS är länkad till laddningshögprofiler i OCPP-backend |
| RD-TM | Lästid (inklusive synkroniseringsstatus, t.ex. "2018-07-24T13:22:04,000+0200 S") | 1,5 och uppåt |
1. MeterValue.timestamp (bastid) 2. JSON i SignedData (synkroniseringsstatus "S/R") |
Konfigurera ClockAlignedDataInterval=900 (15 minuter, anpassas till tidsluckor för mätningsreglering) |
| RD-RV | Mätaravläsning (t.ex. 2935,6 kWh) | 1,5 och uppåt |
1. MeterValue.value (råformat, för snabb visning) 2. JSON i SignedData (signerat format, för faktureringsverifiering) |
Konfigurera MeterValue.sAlignedData=Active.Energy.Register.Import |
| RD-TX | Transaktionsstatus (t.ex. B=Start, E=Slut, T=Taxeändring) | 1,5 och uppåt |
1. StartTransaction.req → TransactionStatus 2. StopTransaction.req → Reason 3. MeterValue.req → JSON i SignedData |
Konfigurera StopTransactionsSignatureFormat=MR/SR (MR: enkel överföring av start/stopp-data; SR: två separata överföringar) |
| LC | Kabelförlustkompensation (inklusive LR-resistans, LU-enhet, etc.) | 2.0 och uppåt | JSON i SignedData (nytt fält i OCMF 1.2.0) | Uppgradera OCPP-protokollet till 2.0+; konfigurera "kabelförlustalgoritmparametrar" i laddningshögstyrenheten |
| IS | Användarbehörighetsstatus (true=Auktoriserad, falsk=Obehörig) | 2.0 och uppåt |
1. Authorize.req → IdTagInfo.Status 2. JSON i SignedData (ÄR bunden till OCPP-auktoriseringsresultat) |
Konfigurera OCPP_AUTH_TLS (auktorisera data via TLS-chiffertext) |
| DET | Användaridentifikationstyp (t.ex. ISO14443=RFID-kort) | 2.0 och uppåt | Authorize.req → IdTagType (eller JSON i SignedData) | Konfigurera "mappning mellan identifieringstyp och IdTag" i OCPP-backend (t.ex. ISO14443 motsvarar OCPP IdTag i 16-siffrigt hex-format) |
| SD | Digital signaturdata (ECDSA-krypteringsresultat) | 1,5 och uppåt |
1. MeterValue.req → Value (ValueFormat=SignedData, kodad som hex) 2. StopTransaction.req → TransactionSignature |
1. Konfigurera SignatureAlgorithm=ECDSA-secp256r1-SHA256 (OCMF standardalgoritm) 2. Aktivera MeterValuesSignatureContext=CSL/RW (ange signaturtriggerpunkter) |
| PG | Sideringsidentifierare (t.ex. T12345=läsning för transaktion 12345) | 1,5 och uppåt | JSON i SignedData (bunden till OCPP:s TransactionId) | Konfigurera "kontinuitetskontroll för paginering" (OCPP-backend verifierar sekventiella PG-nummer, t.ex. T1→T2→T3, för att undvika dataförlust) |
Kompletterande anmärkningar
1. Regler för enhetligt överföringsformat: Alla OCMF-fält är inkapslade i formatet "SignedData" i OCPP – det vill säga OCMF|
2. Gränser för versionskompatibilitet:
● OCPP 1.5: Stöder endast grundläggande OCMF-fält (som FV, GS, RD-RV, SD), och stöder inte högre versionsfält (LC, IT av typen ISO15118);
● OCPP 2.0 och högre: Stöder fullt ut alla fält av OCMF 1.2.0 och lägre, och kan utökas för att ta emot framtida OCMF-tillägg genom fältet "CustomData".
3. Konfigurationsprioritet: När OCPP-konfigurationen står i konflikt med OCMF-kraven (t.ex. OCPPs ClockAlignedDataInterval ≠ 15 minuter), måste OCMF-mätningsföreskrifterna ha företräde (t.ex. tvångsjusteras till 900 sekunder) för att säkerställa att data överensstämmer med kalibreringens juridiska giltighet.
Sammanfattning: Varför blir OCMF en viktig standard i branschen?
I den snabbt utvecklande industrin för laddning av elfordon är trovärdigheten och driftskompatibiliteten för mätdata de viktigaste flaskhalsarna. OCMF, genom sin kombination av "enhetligt format + krypterad verifiering + flexibel anpassning", adresserar användarens primära oro för "rättvis fakturering", minskar tekniska anpassningskostnader för företag och tillhandahåller ett transparent verktyg för reglering, vilket verkligen uppnår en win-win-situation för alla parter.
I takt med att fler och fler tillverkare av laddhögar och operatörer antar OCMF-standarden kommer laddningsupplevelsen att bli bekvämare i framtiden – användare kan med tillförsikt använda alla märken av laddhög och betala betalningar smidigt mellan olika operatörsplattformar. Detta är kärnvärdet som öppna standarder tillför branschen.
