商用充電事業者向けOCPP 1.6Jと2.0.1の戦略的比較

世界の商用充電事業者向けOCPP 1.6Jと2.0.1の決定的な戦略的比較：ネットワークのスケーラビリティ、高度なサイバーセキュリティ、ISO 15118統合、持続可能なEV成長のための長期的なインフラストラクチャの将来性確保

エグゼクティブサマリー

電気自動車（EV）の充電環境は、まさに激変期を迎えています。世界的な普及が加速するにつれ、電気自動車充電設備（EVSE）と充電ステーション管理システム（CSMS）間の通信を規定する基盤となる通信プロトコルが、商用充電事業者（CPO）の技術戦略における重要な焦点となっています。Open Charge Alliance（OCA）が維持管理するOpen Charge Point Protocol（OCPP）は、シンプルなメッセージングフレームワークから、高度で安全かつ拡張性の高い標準規格へと進化を遂げました。

このガイドでは、OCPP 1.6JからOCPP 2.0.1への移行に関する包括的な技術分析を提供します。アーキテクチャの違い、セキュリティ強化、デバイス管理パラダイム、そしてISO 15118統合の重要な役割について詳しく解説します。購入者と運用担当者にとって、この記事は急速に成熟する市場において、情報に基づいた調達と移行の意思決定を行うための決定的な参考資料となります。

第1章：電気自動車充電規格の進化：歴史的背景

オープン充電ポイントプロトコル（OCPP）は、相互運用性の必要性から生まれました。電気自動車（EV）充電の黎明期には、ハードウェアメーカーとソフトウェアプロバイダーがそれぞれ独自のプロトコルを使用し、競争とイノベーションを阻害する「囲い込み」状態を作り出していました。OCPP 1.2と1.5の導入は基礎を築きましたが、業界を真に統合したのはOCPP 1.6でした。

1.1 OCPP 1.6Jの優位性

2015年にリリースされたOCPP 1.6では、WebSockets上のJSON（1.6J）実装が導入されました。SOAPベースのメッセージングからの脱却により、オーバーヘッドが大幅に削減され、開発者にとって実装が簡素化されました。スマート充電や追加のステータス通知などの機能が導入され、10年近くにわたり業界標準となりました。

1.2 OCPP 2.0.1の誕生

1.6Jの成功にもかかわらず、業界の成長に伴い、その限界が露呈しました。セキュリティ、デバイス管理の複雑さ、高度なグリッド統合（V2G）に対するネイティブサポートの欠如といった問題が、OCPP 2.0の開発、そしてその後の改良版であるOCPP 2.0.1（2020年リリース）の開発につながりました。OCPP 2.0.1は単なるアップデートではなく、次世代の高出力、スマート、そして安全な充電ネットワークをサポートすることを目的とした、全面的な再設計です。

第2章：基盤となる通信パラダイム：JSON、WebSocket、およびフレーム構造

これらのプロトコルの違いを理解するには、低レベルの通信に着目する必要がある。どちらのプロトコルもWebSocket上でJSONを使用するが、メッセージの構造と処理方法は大きく異なる。

2.1 WebSocketレイヤー

どちらのバージョンも、全二重通信を可能にする永続的なWebSocket接続を利用しています。これは、モバイルアプリからの充電セッションの停止や、瞬時の障害アラートの受信など、リアルタイム操作にとって非常に重要です。

2.2 メッセージフレームの内訳

一般的なOCPPメッセージは、メッセージタイプID、一意のメッセージID、アクション名、およびペイロードで構成されます。

OCPP 1.6J フレームの例 (ブート通知)

「json [2, "123456", "BootNotification", { "chargePointVendor": "MidaPower", "chargePointModel": "Terra-X", "chargePointSerialNumber": "SN001", "firmwareVersion": "v1.2.3" }]「

OCPP 2.0.1 フレーム例 (ブート通知)

「json [2, "987654", "BootNotification", { "reason": "PowerUp", "chargingStation": { "vendorName": "MidaPower", "model": "Terra-Z", "serialNumber": "SN-Z-99", "firmwareVersion": "v2.0.0" } }]`2.0.1では粒度が増していることに注目してください。reason` フィールドを使用すると、CSMS は起動が再起動、電源投入、またはウォッチドッグ トリガーによるものかどうかを理解でき、より優れた診断ロジックが可能になります。

第3章：アーキテクチャのパラダイムシフト：デバイスモデル

OCPP 2.0.1 における最も重要な技術的変更点は、デバイスモデル.

3.1 1.6J構成キーの制限事項

OCPP 1.6J では、ハードウェア構成は「構成キー」のフラット リスト (例:心拍間隔, 接続タイムアウト充電器が複雑化するにつれて（マルチコネクタ、統合型電源モジュール、複雑な冷却システムなど）、この単純なリストは管理不能になった。充電ステーションの物理的な階層構造を記述する標準的な方法はなかった。

3.2 デバイスモデル2.0.1アプローチ

OCPP 2.0.1では、以下の階層モデルが導入されています。コンポーネントそして変数コンポーネントは、「コントローラ」、「コネクタ」、または「パワーモジュール」のいずれかです。各コンポーネントには、その状態または構成を表す変数があります（例：温度, 電圧, 最大電流).

• 成分充電ステーションの物理的または論理的な構成要素。
• 変数そのコンポーネントの特定の属性。
• 特徴変数を記述するメタデータ（単位、範囲、アクセスタイプ）。

これにより、標準化された監視が可能になります。オペレーターは、ベンダー固有の独自キーに頼るのではなく、標準化された経路を使用して特定の電源モジュールの温度を照会できるようになります。

第4章：サイバーセキュリティ：「ベストエフォート」からTLSの義務化へ

電気自動車の充電が始まった当初は、セキュリティはしばしば後回しにされていた。OCPP 1.6Jはセキュリティプロファイルを提供していたが、ベンダーによって実装方法にばらつきがあった。

4.1 1.6J のセキュリティ プロファイル

OCPP 1.6Jでは、3つのセキュリティプロファイルが定義されています。

1. 担保なし: プレーンテキストの HTTP/WebSockets。
2. 基本認証ユーザー名/パスワードによるTLS接続。
3. 証明書ベースクライアント側証明書を使用したTLS。

問題は、多くの充電器がプロファイル1のままになっており、中間者攻撃（MITM攻撃）や不正な制御に対して脆弱な状態になっていたことだった。

4.2 2.0.1の強硬姿勢

OCPP 2.0.1は安全な通信を義務付けています。高度なセキュリティ機能をネイティブに統合しています。

• 安全なファームウェアアップデートファームウェアイメージの署名と検証が必須です。
• セキュリティログセキュリティ関連イベント（例：ログイン失敗、証明書の有効期限切れ）の詳細ログ。
• 証明書管理: 証明書のローテーションおよび更新に関する標準化されたメッセージ（CSMS主導またはステーション主導）。
• TLS 1.2/1.3最新の暗号化規格に対応しています。

商用事業者にとって、これは大規模なネットワーク侵害のリスクを軽減し、IoTデバイスに関する新たなサイバーセキュリティ規制への準拠を保証する。

第5章：ISO 15118統合：プラグ＆チャージとV2G

電気自動車の充電の未来は、単に電子を移動させることだけではありません。データとエネルギーのインテリジェントな交換が鍵となります。ISO 15118は、車両間通信（V2G）の国際規格であり、OCPPとの統合はバージョン2.0.1の決定的な特徴です。

5.1 プラグアンドチャージの複雑さ

プラグ＆チャージ（PnC）は、ドライバーがアプリやRFIDカードを使用せずに、車両にプラグを差し込むだけで充電を開始できる技術です。ただし、これには車両、充電器、事業者、決済機関を含む複雑な公開鍵基盤（PKI）が必要です。

OCPP 1.6Jでは、基本プロトコルにPnCサポートがありませんでした。ベンダーは独自の拡張機能を実装する必要があり、断片化を招いていました。OCPP 2.0.1は、以下のサポートによりPnCの「基盤」を提供します。

• 証明書のインストール: CSMSからEVSEを介してEVへ契約証明書を渡す。
• 承認車両の証明書から取得したeモビリティID（eMAID）を使用します。
• 暗号化通信車両と電力網の間でやり取りされる機密性の高い課金データが保護されることを保証する。

5.2 スマート充電と負荷分散

1.6Jは基本的なスマート充電（充電プロファイルの設定）、2.0.1ではこれがさらに強化されます。これにより、以下のことが可能になります。

• 外部信号統合：送電網の周波数や卸売価格の信号に対するリアルタイム応答。
• 動的負荷管理数百個のコネクタを備えたサイト全体の電力分配をよりきめ細かく制御できます。
• 車両間電力網接続（V2G）: 2.0.1には双方向のエネルギーの流れをサポートするために必要なデータフィールドが含まれており、EVがグリッドの分散型エネルギー資源（DER）として機能することを可能にします。

5.3 ユーザーUI/UXの改善

OCPP 2.0.1は、充電器の画面または車両のダッシュボードに、次のような情報を直接表示することをサポートしています。

• 現地通貨でのリアルタイム価格表示。
• バッテリー残量80%（SoC）に達するまでの推定時間。
• 完了後、詳細な領収書情報をお知らせします。

第6章：高度なデバイス管理と監視

CPO（認定販売業者）にとって、充電器のコストは購入価格だけではなく、総所有コスト（TCO）も含まれます。メンテナンスとダウンタイムは、利益を最も大きく損なう要因です。OCPP 2.0.1は、優れた監視機能によってこの問題を解決します。

6.1 イベント駆動型レポート

1.6Jでは、CSMSは通常、充電器の状態をポーリングするか、ステータス通知2.0.1では、イベント監視このシステムでは、CSMSがしきい値を設定できます。例えば、「内部温度が70℃を超えた場合のみ通知する」や「入力電圧が200Vを下回った場合に報告する」といった設定が可能です。これにより、ネットワークトラフィックが削減され、予防保全が可能になります。

6.2 トランザクション処理：トランザクションイベント

OCPP 1.6Jで最も批判された点の1つは、トランザクションの処理方法でした。セッションでは、トランザクションの開始そして取引停止メッセージは送信できたものの、ネットワーク障害が発生すると、CSMSは請求データの照合に苦労することが多かった。

OCPP 2.0.1 ではこれらを単一の堅牢なものに置き換えていますトランザクションイベントメッセージ。このメッセージは、トランザクションのすべてのライフサイクル段階（開始、更新、終了）を報告するために使用されます。一意のトランザクションID充電器が再起動してもこの機能は維持されるため、充電データ、ひいては収益が失われることはありません。

6.3 診断およびトラブルシューティング機能の改善

のログを取得そして診断ステータス通知バージョン2.0.1では、メッセージの構造がより明確になりました。CPOは特定のログタイプ（セキュリティ、診断、ユーザー）を要求し、期間を指定できます。これにより、リモートサポートチームは技術者を現場に派遣することなく問題を解決でき、運用コストを大幅に削減できます。

第7章：ファームウェア更新メカニズム：信頼性とロールバック

ファームウェアのアップデートは、進化し続けるハードウェアにとって生命線だが、アップデートに失敗すると充電器が使えなくなる可能性がある。

7.1 1.6Jアップデートプロセス

1.6Jでは、ファームウェアのアップデートコマンドは比較的単純だった。充電器がイメージをダウンロードし、インストールを試みるだけだった。複数段階のアップデートや検証済みのロールバックのための標準化された仕組みは存在しなかった。

7.2 2.0.1 マルチステップアップデート

OCPP 2.0.1では、ファームウェアアップデートのためのより洗練されたライフサイクルが導入されています。

1. ダウンロード充電器はイメージを取得し、そのチェックサム/署名を検証します。
2. インストールアップデートはセカンダリパーティションに適用されます。
3. 検証システムは、新しいファームウェアが正しく起動するかどうかを確認します。
4. アクティベーションプライマリパーティションが切り替えられました。

いずれかの手順でエラーが発生した場合、プロトコルでは、充電器が以前の安定バージョンに復帰し、特定のエラーコードをCSMSに報告する方法が規定されています。このレベルの信頼性は、大規模な商用展開においては譲れない要件です。

7.3 署名検証

悪意のある者が不正なファームウェアをアップロードするのを防ぐため、バージョン2.0.1ではデジタル署名の使用が義務付けられています。充電器は、メーカーの秘密鍵で署名されていないコードの実行を拒否するため、ハードウェアレベルのハッキングに対する重要な保護層が追加されます。

第8章：データプライバシー、規制遵守、およびGDPR

電気自動車の充電が日常生活に欠かせないものとなるにつれ、生成される個人データの量は驚異的なものとなっている。たった1回の充電セッションで、利用者の身元、車両の位置情報、移動パターン、そして金融情報までが紐づけられる可能性があるのだ。

8.1 OCPPにおける個人識別情報（PII）

欧州の一般データ保護規則（GDPR）やカリフォルニア州のCCPAのような類似法の文脈では、idタグ（RFID）またはEVCCID（車両識別番号）は個人情報とみなされます。

OCPP 2.0.1 では、データ匿名化のためのより優れた制御が提供されています。たとえば、カスタムデータこれらのフィールドを使用することで、オペレーターは個人情報（PII）をコアプロトコルログに公開することなくメタデータを保存できます。さらに、強化されたセキュリティプロファイルにより、このデータは転送中および保存時の両方で暗号化されます。

8.2 忘れられる権利とデータポータビリティ

2.0.1 デバイスモデルの構造化された性質により、CSMS プロバイダーは「データ削除」リクエストをより簡単に実装できます。1.6J システムでは、さまざまな構成キーやログからユーザー ID のすべてのインスタンスを見つけるのは、手作業による悪夢でした。2.0.1 では、デバイスの状態とトランザクションデータが明確に分離されているため、よりクリーンなデータベースアーキテクチャを実現できます。

8.3 IoTセキュリティ法への準拠

現在、多くの地域でIoTデバイスに固有のパスワードと安全なアップデートメカニズムを義務付ける法律が制定されつつあります。OCPP 2.0.1で必須となっているTLSと署名付きファームウェアは、単なる「あれば便利な」機能ではなく、カリフォルニア州や英国などの市場でハードウェアを販売するための法的要件となっています。

第9章：購入者の視点：TCO、ROI、および戦略的移行

商用充電事業者にとって、1.6Jのままにするか2.0.1Jに移行するかの決定は、経済的な判断となる。

9.1 導入コスト

• OCPP 1.6J導入コストは安く、低価格のハードウェアで広くサポートされているが、メンテナンスやセキュリティリスクといった隠れたコストが高い。
• OCPP 2.0.1EVSE（電気自動車充電設備）には、より高性能なプロセッサとより多くのメモリが必要となります。CSMSの開発コストは、プロトコルの複雑さゆえに高くなります。しかしながら、リモート管理と信頼性の向上により、運用コストを大幅に削減できます。

9.2 「スムーズなアップグレード」という神話

1.6J充電器はソフトウェアで2.0.1にアップグレードできるとよく言われますが、実際にはそうであることはほとんどありません。2.0.1に必要なメモリとCPUの要件（特にTLS証明書の処理や、デバイスモデルの複雑なJSON解析）は、古い1.6Jコントローラーの能力を超えることが多いためです。

9.3 戦略的な移住経路

最高製品責任者（CPO）は、「ハイブリッドネットワーク」アプローチを検討すべきである。

1. レガシーサイト既存の低電力AC充電器については、引き続き1.6Jで動作します。
2. 新たなDC急速充電ステーション: すべての新規高出力展開において、PnCおよびV2Gをサポートすることを義務付ける2.0.1。
3. プロキシソリューション: 1.6JメッセージをCSMS用の2.0.1互換フォーマットに変換できるプロトコルゲートウェイを使用することで、単一の統合管理ダッシュボードを実現できます。

第10章：将来を見据えた対策：OCPP 2.1と自動充電への道

2.0.1が普及しつつある一方で、Open Charge Allianceは既にOCPP 2.1の開発に取り組んでいます。この次期バージョンは、プロトコルの適用範囲をさらに拡大するでしょう。

10.1 双方向充電（V2X）

バージョン2.0.1は基本的なV2Gをサポートしていますが、バージョン2.1ではV2H（Vehicle-to-Home）およびV2B（Vehicle-to-Building）の通信機能が改良され、停電時に電気自動車が家庭に電力を供給したり、商業ビルのピーク需要を抑制したりできるようになります。

10.2 ワイヤレス充電のサポート

自動運転車（AV）の普及に伴い、手動でのプラグ接続は不要になるでしょう。OCPP 2.1では、誘導（ワイヤレス）充電用の標準化されたメッセージが採用され、人間の介入なしに位置合わせやエネルギー伝送を管理できるようになります。

10.3 スマートシティとの統合

今後のバージョンでは、交通管理システムや再生可能エネルギー予測との連携がさらに深まることが期待されます。充電器はリアルタイムのエネルギー市場で電力の入札を行うことが可能になり、充電ネットワークは大規模な仮想発電所（VPP）へと変貌を遂げるでしょう。

技術付録：メッセージ比較の詳細解説

技術的な詳細をより深く理解するために、ここでは2つのバージョン間の具体的なメッセージシーケンスとフレームの違いを分析します。

A.1 承認フロー

1.6Jでは、認証は「承認済み」または「ブロック済み」の二択応答でした。

1.6J AuthorizeResponse:「json [3, "123456", { "idTagInfo": { "status": "Accepted", "expiryDate": "2026-12-31T23:59:59Z" } }]「

2.0.1では、レスポンスに次のようなより多くのコンテキストが含まれます。idTokenユーザーインターフェースの種類と追加情報。

2.0.1 AuthorizeResponse:「json [3, "987654", { "idTokenInfo": { "status": "Accepted", "cacheExpiryDateTime": "2026-12-31T23:59:59Z", "personalMessage": { "format": "UTF8", "content": "おかえりなさい、ジョン！残高は$45.00です" } } }]「

A.2 心拍数と接続管理

OCPP 2.0.1 では、ステーションが「生きている」ことを証明する方法が最適化されています。1.6J では、心拍失敗した場合、ステーションはしばしば再試行を繰り返すだけだった。2.0.1では、ステーションはNotifyEventプライマリバックエンドとのハートビートを維持しながら、セカンダリバックエンドとの接続が失われたことを報告するメカニズム。

A.3 詳細メタデータ表

結論

OCPP 1.6Jから2.0.1への移行は、単なるソフトウェアアップデートではなく、電気自動車エコシステムの根本的な進化を意味します。商用事業者にとって、1.6Jは信頼性の高い過去を象徴するものであり、2.0.1は拡張性、安全性、そしてインテリジェント性を備えた未来を象徴するものです。

今日2.0.1を選択することは、長期的な将来への投資です。これにより、ハードウェアが次世代EVとの互換性を確保し、厳格化するサイバーセキュリティ規制に準拠し、V2Gやスマートグリッド統合といった収益性の高い機会に対応できるようになります。市場の統合が進むにつれ、最も堅牢で柔軟なプロトコルスタックを備えた事業者が、業界をリードしていくことになるでしょう。

第11章：詳細解説：メッセージフロー分析とシーケンス図

この章では、EVSEとCSMS間の相互作用シーケンスを分析し、1.6Jと2.0.1の動作上の違いを明らかにします。

11.1 ブートおよび構成シーケンス

充電器が初めてネットワークに接続する際には、自身を識別し、設定を同期する必要がある。

OCPP 1.6J流量:

1. WebSocket接続: ポート80または443の上に設立されました。
2. ブート通知: ステーションはベンダー、モデル、シリアル番号を送信します。
3. 設定を取得CSMSは現在の状態を確認するためにすべてのキーを要求します。
4. 変更構成: CSMS は特定のキーを更新します (例:心拍間隔).
5. ステータス通知放送局は「利用可能」と報告しています。

OCPP 2.0.1 フロー:

1. 安全なTLSハンドシェイク証明書の交換は義務付けられています。
2. ブート通知: 含まれる理由（例えば、パワーアップ).
3. GetBaseReportCSMSは、すべてのキーを要求する代わりに、デバイスモデルの完全な階層構造を提供する「基本レポート」を要求します。
4. 変数を設定するCSMSは変数を更新します。バージョン2.0.1では、アトミック更新が可能になりました。つまり、1つのメッセージで複数の変数を設定し、すべて成功するか、まったく成功しないかのどちらかになります。
5. NotifyEventステーションは初期コンポーネントの状態を報告します。

11.2 スマート充電の交渉

スマート充電は、特に複数の充電プロファイルを扱う際に、バージョン2.0.1の真価を発揮する部分です。

1.6Jでは、CSMSは充電プロファイルの設定これはスタックレベルとスケジュールを定義します。ステーションに複数のコネクタがある場合、プロファイルの処理が曖昧になることがよくあります。

2.0.1では、充電プロファイルの設定に明示的にリンクされています充電プロファイルの目的.

• 充電ステーション最大プロファイル駅全体の取水量を制限します。
• TXDefaultProfile新規取引のデフォルト設定。
• TXプロファイル進行中の取引に特有のものです。

さらに、2.0.1 は以下をサポートしています。GetChargingStackLevelこのメッセージにより、CSMSは現在どのプロファイルがアクティブになっているか、またEVSEの内部スケジューラによってどのように優先順位が付けられているかを確認できます。

11.3 リモートトリガーと制御

リモートコマンドリモートスタートトランザクション（1.6J）は以下に置き換えられましたRequestStartTransaction（2.0.1）。主な違いはペイロードにあります。2.0.1では、CSMSには以下を含めることができます。充電プロファイル始動要求に直接含めることで、車両は2つ目のメッセージを待つことなく、適切な電力レベルで即座に充電を開始できるため、遅延が削減され、電力網の安定性が向上します。

第12章：低レベルJSONスキーマとフィールド比較

開発者やシステムインテグレーターにとって、スキーマの変更は移行作業の中で最も手間のかかる部分である。

12.1 列挙型（列挙型）

OCPP 2.0.1では、標準化された列挙型の数が大幅に増加し、1.6Jの実装で問題となっていた「カスタム」ステータスコードの必要性が軽減されました。

• 理由列挙型: 監視犬, スケジュールリセット, リモートリセット, 電力損失.
• ステータス列挙型: 占有中, 予約済み, 利用不可, 欠陥がある. 2.0.1 では、利用可能, 占有中, 予約済み, 利用不可, 欠陥があるただし、より詳細な情報を示すためのサブステータスも用意されています。

12.2 データ型と単位

OCPP 2.0.1 では、標準単位 (SI) の使用が正式に規定されています。1.6J では小数点以下の精度が定義されていない場合がありましたが、2.0.1 では、小数電力およびエネルギー値の種類を指定することで、異なるベンダーのハードウェア間でも一貫した課金を実現します。

第13章：ケーススタディ：グローバルCPOの1.6Jから2.0.1への移行

1万個の充電ポイントを持つCPO（認定充電事業者）である「メガチャージ」という架空のシナリオを見てみましょう。

13.1 フェーズ1：監査

MegaCharge社は、自社の1.6J充電器の40%がTLS 1.2に対応していないことを発見した。これは、これらの充電器が今後の政府契約の対象外となることを意味していた。

13.2 フェーズ2：CSMSのアップグレード

MegaChargeは、新しいCSMSを構築する代わりに、「OCPP変換レイヤー」を実装しました。このレイヤーは、旧型ハードウェア向けの1.6J接続と新型ハードウェア向けの2.0.1接続を処理しつつ、モバイルアプリと課金エンジンに統一されたAPIを提供しました。

13.3 フェーズ3：ハードウェアの交換

トラフィック量の多いサイトでは、MegaChargeは1.6J充電器を2.0.1準拠のDC急速充電器に交換しました。その結果、「起動失敗」セッションが15%減少しました。これは主に、より堅牢な充電器の導入によるものです。トランザクションイベントバージョン2.0.1での処理。

13.4 投資対効果（ROI）分析

初期投資額は200万ドルでした。しかし、デバイスモデルの診断機能のおかげでメンテナンスコールが削減され、年間40万ドルのコスト削減につながりました。さらに、V2G周波数応答市場への参加が可能になったことで、年間20万ドルの追加収益が得られました。投資回収期間は約3.3年でした。

第14章：OCPP 2.0.1調達のためのバイヤー向け究極チェックリスト

新しいハードウェアやソフトウェアを評価する際は、以下のチェックリストを使用して、真の準拠性を確認してください。

14.1 ハードウェア（EVSE）要件

• [ ]セキュリティプロファイル3のサポートクライアント側の証明書管理をサポートしていますか？
• [ ]デュアルコアプロセッサTLS暗号化とJSON解析のための十分な余裕はありますか？
• [ ]セキュアエレメント（SE）: このボードには、鍵を保存するためのハードウェア上の信頼の基点がありますか？
• [ ]ISO 15118-2/20 準備完了コントローラは、PnCに必要な高度な通信を処理できますか？
• [ ]表示機能ハードウェアはOCPP経由での価格/ステータス情報の表示をサポートしていますか？データ転送それともネイティブメッセージ？

14.2 ソフトウェア（CSMS）の要件

• [ ]デバイスモデルの可視化ダッシュボードに充電器の階層構造を表示できますか？
• [ ]認証局（CA）統合CSMSは証明書を自動的に発行および更新できますか？
• [ ]取引照合: 1.6Jの旧型充電器からの「保留状態」のトランザクションは、システムではどのように処理されますか？
• [ ]スマート充電エンジン: 2.0.1の高度なスタックレベルロジックをサポートしていますか？
• [ ]拡張性WebSocketハンドラは、50,000以上の永続的なTLS接続を同時に管理できますか？

第15章：OCPP実装における一般的な問題のトラブルシューティング

標準規格があっても、実装方法は様々です。ここでは、よくある落とし穴をいくつかご紹介します。

15.1 WebSocketタイムアウト

多くのネットワークファイアウォールはアイドル状態のTCP接続を閉じます。心拍間隔設定値が高すぎると、充電器が接続されなくなる可能性があります。

• 解決： 確保する心拍間隔ファイアウォールのタイムアウト（通常60～120秒）よりも短い値です。

15.2 証明書チェーンの問題

バージョン2.0.1でよく発生する不具合の一つに、「信頼されていない証明書」エラーがあります。これは通常、充電器にCSMSのルートCAがインストールされていない場合に発生します。

• 解決: 使用する証明書のインストール試運転中にメッセージを送信し、信頼関係が完全に構築されていることを確認する。

15.3 JSONペイロードサイズ

2.0.1 メッセージの一部 (例:GetBaseReport）は非常に大きくなる可能性があります。充電器のバッファが小さすぎると、メッセージが破棄されます。

• 解決: チェック最大メッセージサイズデバイスモデル内の変数を設定し、CSMSがこの制限を遵守するようにしてください。

第16章：地域ごとの規制状況と議定書の義務

OCPP 2.0.1への移行は、技術的な要因だけではなく、ますます法律上の問題にもなっている。

16.1 欧州連合（AFIR）

EUの代替燃料インフラ規制（AFIR）は、価格の透明性と相互運用性を義務付けている。OCPP 2.0.1を明示的に指定してはいないものの、「リアルタイムデータ共有」と「スマート充電」の要件により、事実上2.0.1が新たな公共インフラにとって唯一実現可能な標準規格となっている。

16.2 北米 (NEVI)

米国では、国家電気自動車インフラ（NEVI）方式プログラムにおいて、充電器の「相互運用性」が義務付けられています。カリフォルニア州のような州はさらに踏み込んでおり、カリフォルニア州エネルギー委員会（CEC）はISO 15118のサポートを推進しています。これは、既に述べたように、OCPP 2.0.1を介して実装するのが最適です。

16.3 中国およびアジア太平洋地域

中国には独自の規格（GB/T）があるものの、輸出を重視するメーカーはOCPP 2.0.1に多額の投資を行っている。オーストラリアやシンガポールなどの市場では、公共充電ネットワークの政府入札において、セキュリティプロファイル3を備えたOCPP 2.0.1がほぼ例外なく指定されている。

第17章：実装コードスニペット：「細かい部分」

開発者を支援するため、複雑な2.0.1タスクの概念的なJSON表現を提供します。

17.1 証明書ローテーションフロー

証明書の有効期限が近づくと、CSMSはローテーションをトリガーする必要があります。

1. CSMSが送信します証明書署名済み:「json [2, "CERT-01", "CertificateSigned", { "certificateChain": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----", "certificateType": "V2G" }]「

2. 駅が応答する承認済み:「json [3, "CERT-01", { "status": "Accepted" }]「

3. ステーションが送信しますセキュリティイベント通知:「json [2, "EVT-99", "SecurityEventNotification", { "type": "CertificateRotated", "timestamp": "2026-08-09T10:00:00Z" }]「

17.2 グリッド応答型充電プロファイルの設定

電力網の運用者が、ネットワーク全体で電力供給を抑制する必要があると想像してみてください。

CSMS 送信充電プロファイルの設定:「json [2, "GRID-REQ", "SetChargingProfile", { "evseId": 0, "chargingProfile": { "id": 501, "stackLevel": 1, "chargingProfilePurpose": "ChargingStationMaxProfile", "chargingProfileKind": "Absolute", "chargingSchedule": { "id": 1, "chargingRateUnit": "W", "chargingSchedulePeriod": [ { "startPeriod": 0, "limit": 11000 }, { "startPeriod": 3600, "limit": 22000 } ] } } }]「

第18章：OCPP 2.0.1用語の総合用語集

すべての関係者の皆様に分かりやすくご説明するため、用語集を拡充いたしました。

• CSMS（充電ステーション管理システム）充電器を制御するバックエンドのクラウドプラットフォーム。
• EVSE（電気自動車用充電設備）物理的な充電ステーション。
• OCPP（オープン充電ポイントプロトコル）彼らが話す言語。
• OCA（オープンチャージアライアンス）: 言語を作成する組織。
• ISO 15118: 車と充電器間のプロトコル。
• PnC（プラグアンドチャージ）ISO 15118およびOCPP 2.0.1によって実現されるユーザーエクスペリエンス。
• V2G（車両間電力供給）：車から電力網へ電力を送り返す。
• V2X（車両間通信）V2G、V2H、V2Bを包括する用語。
• TLS（トランスポート層セキュリティ）: データを安全に保つための暗号化。
• PKI（公開鍵基盤）セキュリティのために使用されるデジタル証明書のシステム。
• JSON（JavaScript Object Notation）メッセージのフォーマット。
• WebSocketメッセージが流れる永続的な接続「パイプ」。
• デバイスモデル: 2.0.1 では、ハードウェアを階層的に記述する方法が示されています。
• 成分ハードウェアの一部（例：コネクタ）。
• 変数: コンポーネントのプロパティ（例：ステータス）。
• 属性変数に関するメタデータ（例：値、変更可能性）。
• トランザクションイベント: 2.0.1 では、すべてのセッションデータ用の統一メッセージが使用されます。
• 心拍：定期的に発信される「私は生きている」信号。
• ブート通知充電器が起動した際に発せられる「こんにちは、ここにいます」という信号。
• データ転送ベンダー固有の拡張機能に対する「包括的な」メッセージ（使用には注意が必要！）。

最終的な考察：マルチプロトコル時代を乗り切る

買い手または運営者として最も重要なことは、私たちがマルチプロトコル時代今後3～5年間は、1.6Jと2.0.1が共存するだろう。しかし、そのバランスは急速に変化している。

今日OCPP 2.0.1を選択するということは、単にプロトコルを購入するだけでなく、保険を購入するようなものです。新しい車両、新しい法律、そして新しい収益源にネットワークが適応できることを保証するのです。2.0.1の複雑さは進歩の代償であり、稼働時間の向上、リスクの低減、そして優れた顧客体験によって、その代償は十分に報われるでしょう。

商用充電はもはやニッチな産業ではなく、未来の交通システムの基盤となるものです。その基盤を、可能な限り強固な土台の上に構築しましょう。それがOCPP 2.0.1です。

第19章：OCPP 2.0.1に対応した開発：ソフトウェアエンジニアのためのベストプラクティス

1.6Jのコードベースから2.0.1への移行は、リファクタリングではなく、書き直しです。開発者は、これまでとは異なる思考モデルを採用する必要があります。

19.1 非同期性を受け入れる

WebSocketは本質的に非同期ですが、2.0.1の複雑さにより、単一のリクエスト（GetBaseReportリソースが限られたEVSEでは、処理に数秒かかる場合があります。CSMS開発者は、ハードウェアベンダーによって処理速度が異なることを考慮し、堅牢なタイムアウトおよび再試行ロジックを実装する必要があります。

19.2 効率的なJSON解析

JSON解析はCPU負荷が高い場合があります。EVSEファームウェアの場合、開発者はペイロード全体をRAMにロードするのではなく、ストリームベースのパーサーを使用する必要があります。これは特に、NotifyEvent1つのフレーム内に数百もの変数更新が含まれる可能性のあるメッセージ。

19.3 ステートマシンの扱い方

2.0.1 のトランザクションの状態マシンは 1.6J よりも厳格です。開発者は、遷移ルール​​を厳密に守る必要があります。トランザクションイベント例えば、終了しましたイベントを最初に送信せずに開始しましたその特定のイベントトランザクションID.

第20章：テスト、検証、およびOCPP準拠テストツール（OCTT）

OCPPは相互運用性を約束するものだが、それは厳格なテストを通してのみ実現される。

20.1 OCA認証の役割

Open Charge Allianceは認証プログラムを提供しています。購入者は「OCPP 2.0.1 Certified」ラベルを探してください。この認証は、実装がすべての必須プロファイルを網羅する一連の自動テストに合格していることを保証します。

20.2 OCTTの使用

OCPP準拠性テストツール（OCTT）は、テストにおけるゴールドスタンダードです。CSMSとEVSEの両方をシミュレートします。

• EVSEメーカー向けOCTTを使用して、ステーションが「正常な動作」シナリオとエッジケース（ファームウェアアップデート中のネットワーク切断など）の両方に対応できることを確認してください。
• CSMSプロバイダー向け: OCTT を使用して、バックエンドが 2.0.1 の膨大な種類のメッセージと厳格なセキュリティ要件を処理できることを確認してください。

20.3 フィールドテストと相互運用性フェスティバル

OCAは自動テストに加え、「プラグフェスト」と呼ばれるイベントも開催しています。これは、ベンダー各社が自社のハードウェアとソフトウェアを持ち寄り、実際の使用環境下で相互にテストを行うものです。証明書の互換性の問題やJSONフォーマットのわずかな違いなど、最も些細なバグもここで発見され、解決されます。

第21章：詳細比較表：OCPP 2.0.1の60以上のアクション

完全な参考資料を提供するために、2.0.1 の主要メッセージを分類し、1.6J の対応するメッセージと比較します。

21.1 プロビジョニングと構成

21.2 トランザクション処理

21.3 セキュリティとファームウェア管理

21.4 この表がネットワークに意味すること

この表から明らかなのは、OCPP 2.0.1 は 1.6J の単なる名称変更ではないということです。新しいメッセージファミリー（型付き変数、イベント駆動型トランザクション、証明書管理）は、プラグ＆チャージ、スマート充電、規制報告に必要な基盤となるものです。1.6J のみに対応する充電器はゲートウェイを追加することで対応できますが、1.6J のみに対応する CSMS では、規制当局や自動車メーカーがますます要求するセキュリティモデルを実現できません。ハードウェアを評価する際には、「2.0.1 対応」とは、ファームウェアが来年ではなく、今日出荷されていることを意味するべきです。また、OCPP 2.0.1 は 1.6J の SOAP トランスポートではなく JSON-over-WebSocket で動作するため、メッセージフローが軽量化され、デバッグがはるかに容易になります。これは、IT チームが初日から実感できる実用的なメリットです。

第22章：結論：アップグレードの決定

商業事業者にとって、実践的な指針は明確です。

• 新規導入では、デフォルトでOCPP 2.0.1を使用する必要があります。セキュリティモデル、証明書の取り扱い、およびISO 15118との統合は、2026年の規制環境に対応するための前提条件です。
• 既存の1.6J型機は座礁状態にはなっていない。マネージドゲートウェイとデュアルプロトコルCSMSプラットフォームは、2.0.1ネイティブハードウェアを段階的に導入する間のギャップを埋める役割を果たします。
• 信頼する前に、必ず検証してください。OCTT、プラグフェスト、段階的展開を活用してください。相互運用性はデータシートから推測されるものではなく、現場で実証されるものです。
• 移住経路を文書で提示するよう要求せよ。充電器のベンダーは、曖昧な約束ではなく、1.6Jから2.0.1までのファームウェアのロードマップを具体的な日付とともに公開すべきです。

行動喚起：MIDA Powerにプロトコル戦略について相談しましょう

MIDA Power ships OCPP 1.6J and 2.0.1 on every charger, with field-upgradeable firmware and a cloud platform that manages mixed-protocol fleets in a single dashboard. Contact sales@midapower.com for our protocol migration guide, OCTT test reports, and a free compatibility review of your existing network.