OCMF は、電気自動車の充電用に特別に設計されたオープンな計量データ交換標準です。標準化された構造、暗号化された署名、および柔軟な適応を通じて、課金メーターの透明性の欠如、データ改ざんの受けやすさ、プロトコルの非互換性という 3 つの主要な業界の問題点に対処します。これにより、請求請求の信頼性が高まり、業界のコラボレーションがより効率的になります。
OCMFとは何ですか?
OCMF（Open Charge Metering Format）は、European Charging Alliance と SAFE{0}}eV 組織によって推進されている業界標準です。これは、充電業界における計量データの「共通言語」のようなもので、充電ステーション、管理システム、オペレーターの間で充電データを送信するための統一ルールを定義します。これにより、充電量、充電時間、コストなどの重要な情報が「理解しやすく、読みやすく、改ざん防止」されることが保証されます。-
簡単に言うと、OCMF が登場する前は、さまざまなブランドの充電ステーションが、地域ごとに異なる方言を話すなど、さまざまなデータ形式を使用していたため、直接通信することは不可能でした。 OCMF では、すべての準拠デバイスが統一された「言語」を使用してデータを送信し、充電の開始から請求の完了までデータが追跡可能で検証可能であることを保証します。
OCMFの主な技術ハイライト
1. 標準化された構造: 「データサイロ」の打破 OCMF は、複雑な追加ヘッダーのない軽量設計を採用しています。コア データは固定フォーマットでカプセル化され、RS-485 などの一般的なシリアル通信シナリオに適応します。これには、充電量 (Wh)、充電時間、デバイス ID、料金情報などの主要なフィールドが含まれており、バージョンの反復と拡張もサポートしています。たとえば、V1.2.0 ではケーブル損失補償データが追加され、V1.3.0 では充電パイル コントローラーのファームウェア バージョン フィールドが追加され、均一性と柔軟性の両方が保証されます。この標準化により、さまざまなブランドの充電パイル、管理プラットフォーム (CSMS)、および支払いシステムが追加の調整なしで相互運用できるようになり、業界のコラボレーション コストが大幅に削減されます。
2. 暗号化と署名のメカニズム: 「データ改ざん」の排除 これは、OCMF の最も重要なセキュリティ設計です。課金パイルによって生成された計量データは送信前に暗号化および署名され、受信者は公開キーを使用してデータの整合性を検証します。これは、データに「セキュリティ ウォーターマーク」を追加するようなものです。改ざんされた場合、検証プロセスが即座にそれを検出し、ソースでの「過請求と不正請求」の問題を防ぎます。
このメカニズムは、ドイツのメス-やアイヒレヒトなどの国際計量規制に完全に準拠しており、充電データを法的に有効にし、ユーザー、事業者、規制当局に信頼の基盤を提供します。
3. マルチプロトコル適応: 「新旧デバイス」との互換性 OCMF は単一の通信プロトコルに限定されず、OCPP 1.6 や OCPP 2.0.1/2.1 などの主流の充電プロトコルに柔軟に適応できます。さまざまなパラメータを構成することで、従来の固定充電シナリオをサポートし、アドホック充電などの新たなニーズにも対応できます。-たとえば、OCPP 2.0.1 システムでは、関連する構成を有効にした後、既存のハードウェアを変更することなく、OCMF が充電の開始と終了などの主要なノードで署名されたデータを自動的に送信できるため、古いデバイスを「信頼できる計測デバイス」にアップグレードできます。
OCMFの実践的な応用
1. アプリケーション シナリオは、充電エコシステム全体をカバーします。
● 充電杭メーカー: OCMF 標準に従って計量モジュールを設計し、別途適応させることなく主要なオペレータ プラットフォームとの直接データ統合を可能にします。
● 充電オペレーター: さまざまなブランドの充電パイルからデータを均一に受信し、バックエンド管理を簡素化し、運用および保守コストを削減します。
● ユーザー: 充電後、ユーザーは暗号化された署名を通じて請求データの信頼性を検証できるため、「法外な充電料金」をめぐる紛争を回避できます。
● 規制当局: 準拠した計測データに直接アクセスすることで、オフサイトの監視が可能になり、業界ガバナンスの効率が向上します。{0}
2. 一般的なワークフロー
● 充電ケーブルを接続すると充電が開始され、充電ステーションは充電量や充電時間などのデータをリアルタイムで記録します。
● データは OCMF 形式でカプセル化され、暗号化アルゴリズムを使用して「デジタル署名」が生成されます。
● 署名された OCMF データ パッケージは、SLIP プロトコル (開始区切り文字と終了区切り文字付き) を介して管理プラットフォームに送信されます。
● プラットフォームは署名を検証した後、データを解析して請求書を生成します。
● 請求が完了すると、完全な OCMF データ レコードを請求伝票として使用して、その後の検証をサポートできます。
OCMF バージョンの進化
継続的に改善されている業界標準 OCMF は、実際の業界のニーズに合わせて、発売以来継続的に反復されてきました。 V1.0.1: 明確化されたバージョン定義と基本的なデータ構造により、標準化の基礎が築かれました。
● V1.1.0: 一時的な課金シナリオに適応する料金表情報を追加しました。
● V1.2.0: 充電中のエネルギー損失の測定課題に対処するために、ケーブル損失補償データを追加しました。
● V1.3.0: デバイス管理の精度を向上させるために、コントローラー ファームウェア バージョン フィールドを追加しました。
各アップデートは「精度の向上、安全性の向上、互換性の向上」という目標を中心に展開されており、標準が常に業界の発展と歩調を合わせられるようにしています。
OCMFコアフィールドとアプリケーションシナリオの参照表
この参照表は、OCMF (Open Charging Measurement Format) バージョン V1.0.1 から V1.3.0 のコア フィールドを要約し、各フィールドの意味、データ型、バージョン サポート、およびコア アプリケーション シナリオを明確にしています。これにより、クイックリファレンスと実際の展開の適応が容易になります。
| フィールド名 | フィールドの意味 | データ型 | バージョンのサポート | コアアプリケーションシナリオ |
|---|---|---|---|---|
| バージョン | OCMF形式のバージョン番号 | 文字列 (例: "1.3.0") | すべてのバージョン | デバイスとプラットフォーム間のバージョン適応のため、データ解析の互換性を確保 |
| GW_ベンダー | ゲートウェイベンダー識別子 | 弦 | V0.4以降 | デバイスのトレーサビリティ。運用および保守管理のために異なるベンダーのゲートウェイを区別する |
| GW_SN | ゲートウェイのシリアル番号 | 文字列 (必須) | V0.4以降 | ゲートウェイデバイスを一意に識別します。計測データを使用して追跡可能なチェーンを形成する |
| メーターベンダー | メータリングモジュールのベンダーID | 弦 | すべてのバージョン | 計量装置のトレーサビリティ。データに関する紛争が発生した場合の責任主体の特定 |
| メーター_SN | 計測モジュールのシリアル番号 | 文字列 (必須) | すべてのバージョン | 計測モジュールを一意に識別します。測定データとデバイス間の 1 対 1 の対応を確保する-{1}} |
| エネルギー | 総充電エネルギー | 数値（単位：Wh） | すべてのバージョン | コアの請求ベース。ユーザー決済とオペレーター調整のための基礎データ |
| 開始時刻 | 充電開始時間 | タイムスタンプ | すべてのバージョン | 充電時間を計算し、時間帯の電気料金を照合して、正確な請求書を生成します。{0} |
| 終了時刻 | 充電終了時間 | タイムスタンプ | すべてのバージョン | 充電サイクルを確認します。開始時刻を使用して合計充電時間を計算する |
| 関税 | 電気料金の情報（時間帯、料金など） | 構造化データ | V1.1.0以降 | 一時的な充電シナリオに適応します。使用時間の料金設定と動的料金決済のサポート-- |
| ケーブル損失 | ケーブル損失補償エネルギー | 数値（単位：Wh） | V1.2.0以降 | 充電中のエネルギー損失を修正します。計測データの精度を確保する |
| 参照 | 充電パイルコントローラーのファームウェアバージョン | 文字列 (オプション) | V1.3.0以降 | ファームウェア管理。メータリングの脆弱性を修正するためにアップグレードが必要かどうかを判断する |
| サイン | デジタル署名 | 暗号化された文字列 | すべてのバージョン | データの偽造防止の検証-請求データの改ざんを防止し、法的有効性を確保します |
| sig_alg | 署名アルゴリズム識別子 | 弦 | V0.4以降 | データの暗号化方法を明確にする。受信者は対応するアルゴリズムで署名を検証します |
| 認証ステータス | 認可ステータス (成功または失敗) | ブール値 | V0.4以降 | 課金トランザクションの正当性を確認します。不正な取引の決済を拒否する |
| イベントカウンター | イベントカウンター | 整数 | V0.4以降 | 充電中の主要なイベントの数を記録します。障害のトラブルシューティングを支援する |
フィールドの優先順位に関する追加の注意:
1. 「必須」とマークされているフィールド (gw_sn、meter_sn、energy など) は、計測データの有効性の基礎です。彼らがいないと正常な決済ができなくなります。
2. バージョンの互換性: 上位バージョンのフィールド (cable_loss、cf など) は、下位バージョンのシステムではオプションです。これらのフィールドが必要な場合は、デバイスを対応するバージョンにアップグレードする必要があります。
3. プロトコルの適応: すべてのフィールドは、フィールド構造に追加の変更を加えることなく、OCPP 1.6 および OCPP 2.0.1/2.1 プロトコルを介して送信できます。
OCMF フィールドと OCPP プロトコルの互換性マッピング テーブル
OCMF は、課金計測データ標準として、デバイス間のデータ送信に OCPP (Open Charge Point Protocol) に依存しています。以下の表は、「OCPP データがどのように送信され、OCPP 内で正常に通信されるか」という実際的な問題に対処するために、さまざまな OCPP バージョンにおける伝送媒体、構成の依存関係、およびコア OCMF フィールドの適応ルールを明確にしています。
| OCMFコアフィールド | フィールドの意味 | サポートされている OCPP バージョン | OCPP伝送キャリア(メッセージ/フィールド) | OCPP 構成の依存関係 |
|---|---|---|---|---|
| FV | OCMF フォーマットのバージョン (例: 1.0、1.2.0) | 1.5以上 | SignedData メタデータ (MeterValue 属性に埋め込まれています) | 追加の構成は必要ありません |
| GS | ゲートウェイのシリアル番号 (署名コンポーネントの一意の識別子) | 1.5以上 |
1. MeterValue.req → SignedData の JSON 2. StopTransaction.req → TransactionData |
「ゲートウェイ-充電パイル バインディング関係」を構成します（例: GS を OCPP の ChargePointIdentity に関連付けます） |
| MS | 計測モジュールのシリアル番号 (固有の計測器識別子) | 1.5以上 | SignedData の JSON (「計測デバイス情報」として MV/MF とグループ化) | 追加の構成はありませんが、MS が OCPP バックエンドの充電パイル プロファイルにリンクされていることを確認してください |
| RD-TM | 時刻の読み取り (同期ステータスを含む、例: "2018-07-24T13:22:04,000+0200 S") | 1.5以上 |
1. MeterValue.timestamp (基準時間) 2. SignedData の JSON (同期ステータス「S/R」) |
ClockAlignedDataInterval=900 を構成します（15 分、計測規制のタイムスロットに合わせます） |
| RD-RV | メーターの読み取り値 (例: 2935.6 kWh) | 1.5以上 |
1. MeterValue.value (生の形式、素早い表示用) 2. SignedData の JSON (署名付き形式、請求検証用) |
MeterValue.sAlignedData=Active.Energy.Register.Import を構成する |
| RD-TX | 取引ステータス (例: B=開始、E=終了、T=料金変更) | 1.5以上 |
1. StartTransaction.req → TransactionStatus 2. StopTransaction.req → 理由 3. MeterValue.req → SignedData の JSON |
StopTransactionsSignatureFormat を構成する=MR/SR (MR: 開始/停止データの 1 回の送信、SR: 2 つの個別の送信) |
| LC | ケーブル損失補償（LR抵抗、LUユニット等を含む） | 2.0以降 | SignedData の JSON (OCMF 1.2.0 の新しいフィールド) | OCPP プロトコルを 2.0+ にアップグレードします。充電パイルコントローラーで「ケーブル損失アルゴリズムパラメータ」を設定する |
| は | ユーザー認証ステータス (true=承認済み、false=未承認) | 2.0以降 |
1. Authorize.req → IdTagInfo.Status 2. SignedData 内の JSON (IS は OCPP 認可結果にバインドされます) |
OCPP_AUTH_TLS を構成する (TLS 暗号文を介してデータを認証する) |
| それ | ユーザー識別タイプ (例: ISO14443=RFID カード) | 2.0以降 | Authorize.req → IdTagType (または SignedData の JSON) | OCPP バックエンドで「識別タイプと IdTag 間のマッピング」を構成します (たとえば、ISO14443 は 16 桁の 16 進数形式の OCPP IdTag に対応します)。 |
| SD | 電子署名データ（ECDSA暗号化結果） | 1.5以上 |
1. MeterValue.req → 値 (ValueFormat=SignedData、16 進数でエンコード) 2. StopTransaction.req → TransactionSignature |
1. SignatureAlgorithm=ECDSA-secp256r1-SHA256 (OCMF デフォルト アルゴリズム) を構成します。 2. MeterValuesSignatureContext=CSL/RW を有効にする（署名トリガー ポイントを指定） |
| PG | ページネーション識別子 (例: トランザクション 12345 の T12345= 読み取り) | 1.5以上 | SignedData の JSON (OCPP の TransactionId にバインド) | 「ページネーション連続性チェック」を設定します (データ損失を避けるために、OCPP バックエンドは連続した PG 番号 (T1→T2→T3 など) を検証します) |
補足事項
1. 統一された送信フォーマット ルール: すべての OCMF フィールドは、OCPP の「SignedData」フォーマットでカプセル化されます。つまり、OCMF|
2. バージョン互換性の境界:
● OCPP 1.5: 基本的な OCMF フィールド (FV、GS、RD-RV、SD など) のみをサポートし、上位バージョンのフィールド (ISO15118 タイプの LC、IT) はサポートしません。
● OCPP 2.0 以降: OCMF 1.2.0 以下のすべてのフィールドを完全にサポートしており、「CustomData」フィールドを通じて将来の OCMF の追加に対応するように拡張できます。
3. 構成の優先順位: OCPP 構成が OCMF 要件と矛盾する場合 (例: OCPP の ClockAlignedDataInterval ≠ 15 分)、データが校正の法的有効性に準拠していることを確認するために、OCMF 計測規則が優先される必要があります (例: 強制的に 900 秒に調整)。
概要: OCMF が業界で不可欠な標準になりつつあるのはなぜですか?
急速に発展する電気自動車充電業界では、メーターデータの信頼性と相互運用性が主要なボトルネックとなっています。 OCMF は、「統一フォーマット + 暗号化検証 + 柔軟な適応」の組み合わせにより、ユーザーの主な懸念である「公平な請求」に対処し、企業の技術適応コストを削減し、規制のための透明なツールを提供して、すべての関係者にとって真に有利な状況を実現します。-
OCMF 標準を採用する充電パイルのメーカーやオペレータが増えるにつれ、将来的には充電エクスペリエンスがより便利になるでしょう。ユーザーは自信を持ってどのブランドの充電パイルも使用でき、さまざまなオペレータ プラットフォーム間でスムーズに支払いを決済できるようになります。これは、オープン スタンダードが業界にもたらす核となる価値です。
