OCMF is een open standaard voor de uitwisseling van meetgegevens, speciaal ontworpen voor het opladen van elektrische voertuigen. Door middel van een gestandaardiseerde structuur, gecodeerde handtekeningen en flexibele aanpassing worden drie belangrijke pijnpunten in de sector aangepakt: gebrek aan transparantie bij het meten van kosten, de gevoeligheid voor geknoei met gegevens en incompatibiliteit van protocollen. Dit maakt de facturering betrouwbaarder en de samenwerking binnen de sector efficiënter.
Wat is OCMF?
OCMF (Open Charge Metering Format) is een industriestandaard die wordt gepromoot door de European Charging Alliance en de SAFE-eV-organisatie. Het is als de ‘gemeenschappelijke taal’ voor meetgegevens in de laadsector, waarbij uniforme regels worden gedefinieerd voor de overdracht van laadgegevens tussen laadstations, managementsystemen en operators. Dit zorgt ervoor dat belangrijke informatie, zoals het oplaadbedrag, de oplaadtijd en de kosten, 'begrijpelijk, leesbaar en fraudebestendig- is.'
Simpel gezegd: vóór OCMF gebruikten verschillende merken laadstations verschillende dataformaten, zoals verschillende regio's die verschillende dialecten spraken, waardoor directe communicatie onmogelijk werd. Met OCMF gebruiken alle compatibele apparaten een uniforme "taal" om gegevens te verzenden, waardoor wordt gegarandeerd dat gegevens traceerbaar en verifieerbaar zijn vanaf het begin van het in rekening brengen tot aan de voltooiing van de facturering.
Belangrijkste technologische hoogtepunten van OCMF
1. Gestandaardiseerde structuur: het afbreken van "datasilo's" OCMF hanteert een lichtgewicht ontwerp zonder complexe extra headers. Kerngegevens zijn ingekapseld in een vast formaat, aangepast aan gangbare seriële communicatiescenario's zoals RS-485. Het bevat belangrijke velden zoals laadbedrag (Wh), oplaadtijd, apparaat-ID en tariefinformatie, en ondersteunt ook versie-iteratie en -uitbreiding. V1.2.0 heeft bijvoorbeeld gegevens over kabelverliescompensatie toegevoegd en V1.3.0 heeft het firmwareversieveld van de laadpaalcontroller toegevoegd, waardoor zowel uniformiteit als flexibiliteit wordt gegarandeerd. Door deze standaardisatie kunnen verschillende merken laadpalen, beheerplatforms (CSMS) en betalingssystemen met elkaar samenwerken zonder aanvullende aanpassingen, waardoor de samenwerkingskosten in de sector aanzienlijk worden verlaagd.
2. Versleutelings- en handtekeningmechanisme: het elimineren van "gegevensmanipulatie" Dit is het meest cruciale beveiligingsontwerp van OCMF. De meetgegevens die door de laadpaal worden gegenereerd, worden vóór verzending gecodeerd en ondertekend, en de ontvanger verifieert de gegevensintegriteit met behulp van een openbare sleutel. Het is alsof je een ‘beveiligingswatermerk’ aan de gegevens toevoegt; Als er mee wordt geknoeid, zal het verificatieproces dit onmiddellijk detecteren, waardoor problemen met "overbelasting en onjuiste facturering" bij de bron worden voorkomen.
Dit mechanisme voldoet volledig aan de internationale metrologische regelgeving zoals de Duitse Mess- & Eichrecht, waardoor laadgegevens juridisch geldig zijn en een basis van vertrouwen worden geboden voor gebruikers, operators en toezichthouders.
3. Multi-Protocolaanpassing: Compatibel met "nieuwe en oude apparaten" OCMF is niet beperkt tot een enkel communicatieprotocol en kan zich flexibel aanpassen aan reguliere oplaadprotocollen zoals OCPP 1.6 en OCPP 2.0.1/2.1. Door verschillende parameters te configureren, kan het traditionele vaste oplaadscenario's ondersteunen en voldoen aan opkomende behoeften zoals ad- adhoc opladen. In een OCPP 2.0.1-systeem kan OCMF bijvoorbeeld, na het inschakelen van de relevante configuratie, automatisch ondertekende gegevens verzenden op belangrijke knooppunten, zoals het begin en einde van het opladen, zonder de bestaande hardware te wijzigen, waardoor oudere apparaten kunnen worden geüpgraded naar 'vertrouwde meetapparaten'.
Praktische toepassingen van OCMF
1. Toepassingsscenario’s bestrijken het gehele laadecosysteem:
● Fabrikanten van laadpalen: Ontwerp meetmodules volgens OCMF-standaarden, waardoor directe data-integratie met grote operatorplatforms mogelijk is zonder afzonderlijke aanpassingen.
● Laadoperatoren: Ontvang op uniforme wijze gegevens van verschillende merken laadpalen, waardoor het backend-beheer wordt vereenvoudigd en de exploitatie- en onderhoudskosten worden verlaagd.
● Gebruikers: Na het in rekening brengen kunnen gebruikers de authenticiteit van de factuurgegevens verifiëren via gecodeerde handtekeningen, waardoor geschillen over 'exorbitante kosten' worden vermeden.
● Regelgevende instanties: rechtstreekse toegang tot meetgegevens die voldoen aan de voorschriften, waardoor extern- toezicht mogelijk wordt en de efficiëntie van het sectorbestuur wordt verbeterd.
2. Typische workflow
● U sluit de laadkabel aan om te beginnen met opladen, en het laadstation registreert gegevens zoals laadbedrag en -tijd in realtime;
● De gegevens worden ingekapseld in OCMF-formaat en er wordt een "digitale handtekening" gegenereerd met behulp van een versleutelingsalgoritme;
● Het ondertekende OCMF-datapakket wordt via het SLIP-protocol (met begin- en eindscheidingstekens) naar het beheerplatform verzonden;
● Nadat het platform de handtekening heeft geverifieerd, parseert het de gegevens en genereert het een factuur;
● Nadat het in rekening brengen is voltooid, kan het volledige OCMF-gegevensrecord worden gebruikt als factureringsvoucher ter ondersteuning van latere verificatie.
OCMF-versie-evolutie
De continu verbeterende industriestandaard OCMF heeft sinds de lancering voortdurend iteraties ondergaan, waarbij deze is aangepast aan de werkelijke behoeften van de industrie: V1.0.1: Verduidelijkte versiedefinitie en basisgegevensstructuur, waarmee de basis wordt gelegd voor standaardisatie;
● V1.1.0: Tariefinformatie toegevoegd om aan te passen aan tijdelijke oplaadscenario's;
● V1.2.0: Gegevens over kabelverliescompensatie toegevoegd om de meetuitdagingen van energieverlies tijdens het opladen aan te pakken;
● V1.3.0: veld voor controllerfirmwareversie toegevoegd om de nauwkeurigheid van apparaatbeheer te verbeteren.
Elke update draait om de doelstellingen van "grotere nauwkeurigheid, grotere veiligheid en grotere compatibiliteit", zodat de standaard altijd gelijke tred houdt met de ontwikkelingen in de sector.
OCMF-kernvelden en toepassingsscenario's referentietabel
Deze referentietabel geeft een samenvatting van de kernvelden van OCMF-versies (Open Charging Measurement Format) V1.0.1 tot V1.3.0, waarbij de betekenis, het gegevenstype, de versieondersteuning en de kerntoepassingsscenario's van elk veld worden verduidelijkt. Het vergemakkelijkt een snelle referentie en praktische aanpassing van de implementatie.
| Veldnaam | Veld betekenis | Gegevenstype | Versie-ondersteuning | Kerntoepassingsscenario's |
|---|---|---|---|---|
| ver | Versienummer van het OCMF-formaat | Tekenreeks (bijvoorbeeld "1.3.0") | Alle versies | Voor versie-aanpassing tussen apparaat en platform, waardoor compatibiliteit met gegevensparsering wordt gegarandeerd |
| gw_leverancier | Identificatie van de gatewayleverancier | Snaar | V0.4 en hoger | Traceerbaarheid van apparaten; maak onderscheid tussen gateways van verschillende leveranciers voor exploitatie- en onderhoudsbeheer |
| gw_sn | Serienummer van de gateway | Tekenreeks (vereist) | V0.4 en hoger | Identificeer gateway-apparaten op unieke wijze; vormen een traceerbare keten met meetgegevens |
| meter_leverancier | Leverancier-ID van meetmodule | Snaar | Alle versies | Traceerbaarheid van meetapparatuur; verantwoordelijke entiteiten lokaliseren in geval van gegevensgeschillen |
| meter_sn | Serienummer van de meetmodule | Tekenreeks (vereist) | Alle versies | Unieke identificatie van meetmodules; zorg voor één-op-één overeenkomst tussen meetgegevens en apparaten |
| energie | Totale laadenergie | Numeriek (eenheid: Wh) | Alle versies | Basisfactureringsbasis; basisgegevens voor gebruikersafrekening en operatorafstemming |
| begintijd | Starttijd opladen | Tijdstempel | Alle versies | Bereken de oplaadduur, pas de elektriciteitsprijzen in de -periode aan en genereer nauwkeurige facturen |
| eindtijd | Eindtijd opladen | Tijdstempel | Alle versies | Bevestig de oplaadcyclus; bereken de totale laadduur met starttijd |
| tarief | Informatie over elektriciteitsprijzen (inclusief tijdsperioden, tarieven) | Gestructureerde gegevens | V1.1.0 en hoger | Aanpassen aan tijdelijke oplaadscenario's; ondersteuningstijd-van-gebruiksprijzen en dynamische tariefafrekening |
| kabelverlies | Energie voor compensatie van kabelverlies | Numeriek (eenheid: Wh) | V1.2.0 en hoger | Corrigeer energieverlies tijdens het opladen; nauwkeurigheid van de meetgegevens garanderen |
| vgl | Firmwareversie van de laadpaalcontroller | Tekenreeks (optioneel) | V1.3.0 en hoger | Firmwarebeheer; bepalen of upgrades nodig zijn om meetkwetsbaarheden op te lossen |
| handtekening | Digitale handtekening | Gecodeerde tekenreeks | Alle versies | Verificatie van gegevens tegen-namaak; voorkomen dat er met factuurgegevens wordt geknoeid en zorgen voor de rechtsgeldigheid |
| sig_alg | Identificatie van handtekeningalgoritme | Snaar | V0.4 en hoger | Verduidelijk de gegevensversleutelingsmethode; ontvanger verifieert handtekening met bijbehorend algoritme |
| auth_status | Autorisatiestatus (succesvol of niet) | Booleaans | V0.4 en hoger | Bevestig de legitimiteit van het in rekening brengen van transacties; vereffening voor ongeautoriseerde transacties afwijzen |
| gebeurtenis_teller | Gebeurtenisteller | Geheel getal | V0.4 en hoger | Registreer tellingen van belangrijke gebeurtenissen tijdens het opladen; helpen bij het oplossen van storingen |
Aanvullende opmerkingen over veldprioriteit:
1. Velden gemarkeerd als "vereist" (zoals gw_sn, meter_sn, energie) zijn van fundamenteel belang voor de geldigheid van meetgegevens; hun afwezigheid zal een normale afwikkeling verhinderen.
2. Versiecompatibiliteit: Velden uit hogere versies (zoals cable_loss, cf) zijn optioneel in systemen met een lagere versie. Als deze velden nodig zijn, is een upgrade van het apparaat naar de overeenkomstige versie vereist.
3. Protocolaanpassing: Alle velden kunnen worden verzonden via de OCPP 1.6- en OCPP 2.0.1/2.1-protocollen zonder dat er aanvullende wijzigingen aan de veldstructuur nodig zijn.
OCMF-veld- en OCPP-protocolcompatibiliteitstoewijzingstabel
OCMF, als standaard voor laadmetingsgegevens, vertrouwt op OCPP (Open Charge Point Protocol) voor gegevensoverdracht tussen apparaten. De onderstaande tabel verduidelijkt het transmissiemedium, de configuratieafhankelijkheden en aanpassingsregels van kern-OCMF-velden in verschillende OCPP-versies, en behandelt de praktische vraag "hoe OCMF-gegevens binnen OCPP worden verzonden en met succes worden gecommuniceerd."
| OCMF-kernveld | Veld betekenis | Ondersteunde OCPP-versie | OCPP-transmissieprovider (bericht/veld) | OCPP-configuratieafhankelijkheid |
|---|---|---|---|---|
| FV | OCMF-formaatversie (bijv. 1.0, 1.2.0) | 1,5 en hoger | SignedData-metagegevens (ingebed in MeterValue-attributen) | Geen aanvullende configuratie vereist |
| GS | Serienummer van de gateway (unieke identificatie voor handtekeningcomponenten) | 1,5 en hoger |
1. MeterValue.req → JSON in SignedData 2. StopTransaction.req → Transactiegegevens |
Configureer de 'gateway-laadstapelbindingsrelatie' (koppel GS bijvoorbeeld aan de ChargePointIdentity van OCPP) |
| MEVROUW | Serienummer van de meetmodule (unieke meteridentificatie) | 1,5 en hoger | JSON in SignedData (gegroepeerd met MV/MF als "metering device info") | Geen extra configuratie, maar zorg ervoor dat MS is gekoppeld aan laadpaalprofielen in de OCPP-backend |
| RD-TM | Leestijd (inclusief synchronisatiestatus, bijvoorbeeld "2018-07-24T13:22:04,000+0200 S") | 1,5 en hoger |
1. MeterValue.timestamp (basistijd) 2. JSON in SignedData (synchronisatiestatus "S/R") |
Configureer ClockAlignedDataInterval=900 (15 minuten, afgestemd op tijdvakken voor meetregulering) |
| RD-camper | Tellerstand (bijv. 2935,6 kWh) | 1,5 en hoger |
1. MeterValue.value (ruw formaat, voor snelle weergave) 2. JSON in SignedData (ondertekend formaat, voor factureringsverificatie) |
MeterValue.sAlignedData configureren=Active.Energy.Register.Import |
| RD-TX | Transactiestatus (bijv. B=Begin, E=Einde, T=Tariefwijziging) | 1,5 en hoger |
1. StartTransaction.req → TransactieStatus 2. StopTransaction.req → Reden 3. MeterValue.req → JSON in SignedData |
StopTransactionsSignatureFormat configureren=MR/SR (MR: enkele verzending van start/stop-gegevens; SR: twee afzonderlijke verzendingen) |
| LC | Compensatie van kabelverlies (inclusief LR-weerstand, LU-eenheid, enz.) | 2.0 en hoger | JSON in SignedData (nieuw veld in OCMF 1.2.0) | Upgrade het OCPP-protocol naar 2.0+; configureer "kabelverliesalgoritmeparameters" in de laadpaalcontroller |
| IS | Autorisatiestatus van gebruiker (true=Geautoriseerd, false=Niet-geautoriseerd) | 2.0 en hoger |
1. Autoriseren.aanvraag → IdTagInfo.Status 2. JSON in SignedData (IS gebonden aan OCPP-autorisatieresultaat) |
OCPP_AUTH_TLS configureren (gegevens autoriseren via TLS-cijfertekst) |
| HET | Type gebruikersidentificatie (bijvoorbeeld ISO14443=RFID-kaart) | 2.0 en hoger | Authorize.req → IdTagType (of JSON in SignedData) | Configureer "toewijzing tussen identificatietype en IdTag" in OCPP-backend (ISO14443 komt bijvoorbeeld overeen met OCPP IdTag in 16-cijferig hexadecimaal formaat) |
| SD | Digitale handtekeninggegevens (ECDSA-coderingsresultaat) | 1,5 en hoger |
1. MeterValue.req → Waarde (ValueFormat=SignedData, gecodeerd als hex) 2. StopTransaction.req → Transactiehandtekening |
1. Configureer SignatureAlgorithm=ECDSA-secp256r1-SHA256 (OCMF-standaardalgoritme) 2. Schakel MeterValuesSignatureContext in=CSL/RW (specificeer handtekeningtriggerpunten) |
| PG | Paginerings-ID (bijv. T12345=lezing voor transactie 12345) | 1,5 en hoger | JSON in SignedData (gebonden aan de TransactionId van OCPP) | Configureer "controle op continuïteit van de paginering" (OCPP-backend verifieert opeenvolgende PG-nummers, bijvoorbeeld T1 → T2 → T3, om gegevensverlies te voorkomen) |
Aanvullende opmerkingen
1. Uniforme regels voor transmissieformaten: Alle OCMF-velden zijn ingekapseld in het "SignedData"-formaat in OCPP – dat wil zeggen, de OCMF|
2. Versiecompatibiliteitsgrenzen:
● OCPP 1.5: ondersteunt alleen standaard OCMF-velden (zoals FV, GS, RD-RV, SD), en ondersteunt geen velden met hogere versies (LC, IT van het type ISO15118);
● OCPP 2.0 en hoger: ondersteunt volledig alle velden van OCMF 1.2.0 en lager, en kan worden uitgebreid om toekomstige OCMF-toevoegingen mogelijk te maken via het veld "CustomData".
3. Configuratieprioriteit: Wanneer de OCPP-configuratie conflicteert met de OCMF-vereisten (bijv. OCPP's ClockAlignedDataInterval ≠ 15 minuten), moeten de OCMF-meetregels voorrang krijgen (bijv. gedwongen worden aangepast naar 900 seconden) om ervoor te zorgen dat de gegevens voldoen aan de wettelijke geldigheid van de kalibratie.
Samenvatting: Waarom wordt OCMF een essentiële standaard in de branche?
In de zich snel ontwikkelende industrie voor het opladen van elektrische voertuigen zijn de geloofwaardigheid en interoperabiliteit van meetgegevens de belangrijkste knelpunten. Door de combinatie van 'uniform formaat + gecodeerde verificatie + flexibele aanpassing' komt OCMF tegemoet aan de voornaamste zorg van de gebruiker, namelijk 'eerlijke facturering', verlaagt het de technische aanpassingskosten voor bedrijven en biedt het een transparant instrument voor regulering, waardoor werkelijk een win-winsituatie voor alle partijen wordt bereikt.
Naarmate steeds meer fabrikanten en exploitanten van laadpalen de OCMF-standaard adopteren, zal de laadervaring in de toekomst gemakkelijker worden – gebruikers kunnen vol vertrouwen elk merk laadpalen gebruiken en betalingen soepel afhandelen via verschillende operatorplatforms. Dit is de kernwaarde die open standaarden voor de industrie met zich meebrengen.
