OCMF is an open metering data exchange standard specifically designed for electric vehicle charging. Through standardized structure, encrypted signatures, and flexible adaptation, it addresses three major industry pain points: lack of transparency in charging metering, susceptibility to data tampering, and protocol incompatibility. This makes charging billing more trustworthy and industry collaboration more efficient.
What is OCMF?
OCMF (Open Charge Metering Format) is an industry standard promoted by the European Charging Alliance and the SAFE-eV organization. It's like the "common language" for metering data in the charging industry, defining unified rules for the transmission of charging data between charging stations, management systems, and operators. This ensures that key information such as charging amount, charging time, and cost is "understandable, readable, and tamper-proof."
Simply put, before OCMF, different brands of charging stations used diverse data formats, like different regions speaking different dialects, making direct communication impossible. With OCMF, all compliant devices use a unified "language" to transmit data, ensuring that data is traceable and verifiable from the start of charging to the completion of billing.
Key Technological Highlights of OCMF
1. Standardized Structure: Breaking Down "Data Silos" OCMF adopts a lightweight design without complex extra headers. Core data is encapsulated in a fixed format, adapting to common serial communication scenarios such as RS-485. It includes key fields such as charging amount (Wh), charging time, device ID, and tariff information, and also supports version iteration and expansion – for example, V1.2.0 added cable loss compensation data, and V1.3.0 added the charging pile controller firmware version field, ensuring both uniformity and flexibility. This standardization allows different brands of charging piles, management platforms (CSMS), and payment systems to interoperate without additional adaptation, significantly reducing industry collaboration costs.
2. Encryption and Signature Mechanism: Eliminating "Data Tampering" This is the most crucial security design of OCMF. The metering data generated by the charging pile is encrypted and signed before transmission, and the recipient verifies data integrity using a public key. It's like adding a "security watermark" to the data; if it's tampered with, the verification process will immediately detect it, preventing "overcharging and incorrect billing" issues at the source.
This mechanism fully complies with international metrology regulations such as the German Mess- & Eichrecht, making charging data legally valid and providing a foundation of trust for users, operators, and regulators.
3. Multi-Protocol Adaptation: Compatible with "New and Old Devices" OCMF is not limited to a single communication protocol and can flexibly adapt to mainstream charging protocols such as OCPP 1.6 and OCPP 2.0.1/2.1. By configuring different parameters, it can support traditional fixed charging scenarios and meet emerging needs such as ad-hoc charging. For example, in an OCPP 2.0.1 system, after enabling the relevant configuration, OCMF can automatically transmit signed data at key nodes such as the start and end of charging, without modifying existing hardware, allowing older devices to be upgraded to "trusted metering devices."
Practical Applications of OCMF
1. Application scenarios cover the entire charging ecosystem:
● Charging pile manufacturers: Design metering modules according to OCMF standards, allowing direct data integration with major operator platforms without separate adaptation.
● Charging operators: Uniformly receive data from different brands of charging piles, simplifying backend management and reducing operation and maintenance costs.
● Users: After charging, users can verify the authenticity of billing data through encrypted signatures, avoiding disputes over "exorbitant charging fees."
● Regulatory agencies: Directly access compliant metering data, enabling off-site supervision and improving the efficiency of industry governance.
2. Typical Workflow
● You plug in the charging cable to start charging, and the charging station records data such as charging amount and time in real time;
● The data is encapsulated in OCMF format, and a "digital signature" is generated using an encryption algorithm;
● The signed OCMF data package is transmitted to the management platform via the SLIP protocol (with start and end delimiters);
● After the platform verifies the signature, it parses the data and generates a bill;
● After charging is completed, the complete OCMF data record can be used as a billing voucher to support subsequent verification.
OCMF Version Evolution
The continuously improving industry standard OCMF has undergone constant iterations since its launch, adapting to actual industry needs: V1.0.1: Clarified version definition and basic data structure, laying the foundation for standardization;
● V1.1.0: Added tariff information to adapt to temporary charging scenarios;
● V1.2.0: Added cable loss compensation data to address the measurement challenges of energy loss during charging;
● V1.3.0: Added controller firmware version field to improve the accuracy of device management.
Each update revolves around the goals of "greater accuracy, greater safety, and greater compatibility," ensuring that the standard always keeps pace with industry development.
OCMF Core Fields and Application Scenarios Reference Table
This reference table summarizes the core fields of OCMF (Open Charging Measurement Format) versions V1.0.1 to V1.3.0, clarifying the meaning, data type, version support, and core application scenarios of each field. It facilitates quick reference and practical deployment adaptation.
| Field Name | Field Meaning | Data Type | Version Support | Core Application Scenarios |
|---|---|---|---|---|
| ver | OCMF format version number | String (e.g., "1.3.0") | All versions | For version adaptation between device and platform, ensuring data parsing compatibility |
| gw_vendor | Gateway vendor identifier | String | V0.4 and above | Device traceability; distinguish gateways from different vendors for operation and maintenance management |
| gw_sn | Gateway serial number | String (required) | V0.4 and above | Uniquely identify gateway devices; form a traceable chain with metering data |
| meter_vendor | Metering module vendor ID | String | All versions | Traceability of metering devices; locate responsible entities in case of data disputes |
| meter_sn | Metering module serial number | String (required) | All versions | Uniquely identify metering modules; ensure one-to-one correspondence between metering data and devices |
| energy | Total charging energy | Numeric (Unit: Wh) | All versions | Core billing basis; basic data for user settlement and operator reconciliation |
| start_time | Charging start time | Timestamp | All versions | Calculate charging duration, match time-period electricity prices, and generate accurate bills |
| end_time | Charging end time | Timestamp | All versions | Confirm charging cycle; calculate total charging duration with start time |
| tariff | Electricity price info (including time periods, rates) | Structured data | V1.1.0 and above | Adapt to temporary charging scenarios; support time-of-use pricing and dynamic tariff settlement |
| cable_loss | Cable loss compensation energy | Numeric (Unit: Wh) | V1.2.0 and above | Correct energy loss during charging; ensure metering data accuracy |
| cf | Charging pile controller firmware version | String (optional) | V1.3.0 and above | Firmware management; determine if upgrades are needed to fix metering vulnerabilities |
| signature | Digital signature | Encrypted string | All versions | Data anti-counterfeiting verification; prevent tampering of billing data and ensure legal validity |
| sig_alg | Signature algorithm identifier | String | V0.4 and above | Clarify data encryption method; receiver verifies signature with corresponding algorithm |
| auth_status | Authorization status (success or not) | Boolean | V0.4 and above | Confirm legitimacy of charging transactions; reject settlement for unauthorized transactions |
| event_counter | Event counter | Integer | V0.4 and above | Record counts of key events during charging; assist in fault troubleshooting |
Additional Notes on Field Priority:
1. Fields marked as "required" (such as gw_sn, meter_sn, energy) are fundamental for the validity of metering data; their absence will prevent normal settlement.
2. Version Compatibility: Fields from higher versions (such as cable_loss, cf) are optional in lower version systems. Upgrading the device to the corresponding version is required if these fields are needed.
3. Protocol Adaptation: All fields can be transmitted via OCPP 1.6 and OCPP 2.0.1/2.1 protocols without requiring any additional modifications to the field structure.
OCMF Field and OCPP Protocol Compatibility Mapping Table
OCMF, as a charging metering data standard, relies on OCPP (Open Charge Point Protocol) for data transmission between devices. The table below clarifies the transmission medium, configuration dependencies, and adaptation rules of core OCMF fields in different OCPP versions, addressing the practical question of "how OCMF data is transmitted and successfully communicated within OCPP."
| OCMF Core Field | Field Meaning | Supported OCPP Version | OCPP Transmission Carrier (Message/Field) | OCPP Configuration Dependency |
|---|---|---|---|---|
| FV | OCMF format version (e.g., 1.0, 1.2.0) | 1.5 and above | SignedData metadata (embedded in MeterValue attributes) | No additional configuration required |
| GS | Gateway serial number (unique identifier for signature components) | 1.5 and above |
1. MeterValue.req → JSON in SignedData 2. StopTransaction.req → TransactionData |
Configure "gateway-charging pile binding relationship" (e.g., associate GS with OCPP's ChargePointIdentity) |
| MS | Metering module serial number (unique meter identifier) | 1.5 and above | JSON in SignedData (grouped with MV/MF as "metering device info") | No additional configuration, but ensure MS is linked to charging pile profiles in OCPP backend |
| RD-TM | Reading time (including sync status, e.g., "2018-07-24T13:22:04,000+0200 S") | 1.5 and above |
1. MeterValue.timestamp (base time) 2. JSON in SignedData (sync status "S/R") |
Configure ClockAlignedDataInterval=900 (15 minutes, aligns with metering regulation time slots) |
| RD-RV | Meter reading (e.g., 2935.6 kWh) | 1.5 and above |
1. MeterValue.value (Raw format, for quick display) 2. JSON in SignedData (Signed format, for billing verification) |
Configure MeterValue.sAlignedData=Active.Energy.Register.Import |
| RD-TX | Transaction status (e.g., B=Start, E=End, T=Tariff Change) | 1.5 and above |
1. StartTransaction.req → TransactionStatus 2. StopTransaction.req → Reason 3. MeterValue.req → JSON in SignedData |
Configure StopTransactionsSignatureFormat=MR/SR (MR: single transmission of start/stop data; SR: two separate transmissions) |
| LC | Cable loss compensation (including LR resistance, LU unit, etc.) | 2.0 and above | JSON in SignedData (new field in OCMF 1.2.0) | Upgrade OCPP protocol to 2.0+; configure "cable loss algorithm parameters" in the charging pile controller |
| IS | User authorization status (true=Authorized, false=Unauthorized) | 2.0 and above |
1. Authorize.req → IdTagInfo.Status 2. JSON in SignedData (IS bound to OCPP authorization result) |
Configure OCPP_AUTH_TLS (authorize data via TLS ciphertext) |
| IT | User identification type (e.g., ISO14443=RFID card) | 2.0 and above | Authorize.req → IdTagType (or JSON in SignedData) | Configure "mapping between identification type and IdTag" in OCPP backend (e.g., ISO14443 corresponds to OCPP IdTag in 16-digit hex format) |
| SD | Digital signature data (ECDSA encryption result) | 1.5 and above |
1. MeterValue.req → Value (ValueFormat=SignedData, encoded as hex) 2. StopTransaction.req → TransactionSignature |
1. Configure SignatureAlgorithm=ECDSA-secp256r1-SHA256 (OCMF default algorithm) 2. Enable MeterValuesSignatureContext=CSL/RW (specify signature trigger points) |
| PG | Pagination identifier (e.g., T12345=reading for transaction 12345) | 1.5 and above | JSON in SignedData (bound to OCPP's TransactionId) | Configure "pagination continuity check" (OCPP backend verifies sequential PG numbers, e.g., T1→T2→T3, to avoid data loss) |
Supplementary Notes
1. Unified Transmission Format Rules: All OCMF fields are encapsulated in the "SignedData" format in OCPP – that is, the OCMF|<payload>|<signature> structure of OCMF. This structure must first be encoded into a hexadecimal string before being inserted into the "Value" field of OCPP MeterValue/StopTransaction (ValueFormat=SignedData). The backend needs to decode the JSON in reverse.
2. Version Compatibility Boundaries:
● OCPP 1.5: Only supports basic OCMF fields (such as FV, GS, RD-RV, SD), and does not support higher version fields (LC, IT of ISO15118 type);
● OCPP 2.0 and above: Fully supports all fields of OCMF 1.2.0 and below, and can be extended to accommodate future OCMF additions through the "CustomData" field.
3. Configuration Priority: When OCPP configuration conflicts with OCMF requirements (e.g., OCPP's ClockAlignedDataInterval ≠ 15 minutes), the OCMF metering regulations must take precedence (e.g., forcibly adjusted to 900 seconds) to ensure that the data complies with calibration legal validity.
Summary: Why is OCMF becoming an essential standard in the industry?
In the rapidly developing electric vehicle charging industry, the credibility and interoperability of metering data are core bottlenecks. OCMF, through its combination of "unified format + encrypted verification + flexible adaptation," addresses the user's primary concern of "fair billing," reduces technical adaptation costs for businesses, and provides a transparent tool for regulation, truly achieving a win-win situation for all parties.
As more and more charging pile manufacturers and operators adopt the OCMF standard, the charging experience will become more convenient in the future – users can confidently use any brand of charging pile and settle payments smoothly across different operator platforms. This is the core value that open standards bring to the industry.
