OCPP 各バージョンの特徴と移行ポイントを 5〜10 分で解説
1. OCPPとは
本記事では歴史的経緯にならい、充電器本体を CP（Charge Point）と表記します。
OCPP 2.x 仕様書で使われる CS = Charging Station は、CP と同義です。
OCPP（Open Charge Point Protocol）は、EV 充電器（Charge Point）と充電器管理システム（CSMS／バックエンド）の通信標準です。充電インフラの相互運用を目的に、オランダの Open Charge Alliance が策定・管理しています。
- 充電器メーカーと運営事業者が異なっても「共通言語」で接続できる
- イーサネット／LTE など transport を問わない
- JSON または SOAP（バージョンにより異なる）でメッセージを交換
2. バージョンの変遷
| バージョン | 年 | 主な特徴 | メッセージ形式 | セキュリティ | 現状の普及度 |
|---|---|---|---|---|---|
| 1.2 | 2010 | 初版。基本的な充電制御のみ | SOAP 1.1 | TLS 任意 | ほぼ置換済み |
| 1.5 | 2012 | 外部リレー制御、スマート充電の基礎 | SOAP 1.2 | TLS 任意 | 一部残存 |
| 1.6 J | 2015 | JSON 版追加（1.6J）、ハートビート導入 | JSON over WebSocket | TLS 推奨 | 現在主流 |
| 2.0 | 2020 | 大幅拡張（RFID、トランザクション、ISO 15118 連携） | JSON over WebSocket | JWS 署名、TLS 必須 | パイロット導入 |
| 2.0.1 | 2021 | 2.0 のフィードバック反映、後方互換 | JSON over WebSocket | JWS 署名、TLS 必須 | 今後本命 |
2.0.1 からは 「セキュリティ標準（OCPP Security Whitepaper）」の遵守が事実上必須 です。TLS 1.2＋クライアント認証、JWS 署名、鍵更新手順などが定義されます。
3. 主要コンポーネントと通信フロー
上図は OCPP 1.6J/2.0.1 共通 の代表的なシーケンスです。2.0.1 では Authorize が Authorize+SecurityEventNotification に分割されるなど、メッセージ粒度が細かくなります。
4. バージョン別の機能差分
4.1 スマート充電
- 1.6J:
SetChargingProfileで電流・電力制御 - 2.0.1: 上記に加え 複数 EVSE、優先度、車両側プロファイル統合 をサポート
4.2 認証方式
| 機能 | 1.6J | 2.0.1 |
|---|---|---|
| RFID (ISO 14443) | ◯ | ◯ |
| プラグ＆チャージ (ISO 15118) | × | ◯ |
| トークン型 (ソフト認証) | △ | ◯ |
4.3 セキュリティ
1.6J では TLS 任意 だったため実装依存でしたが、2.0.1 では以下が必須になります。
- TLS 1.2 以上（クライアント証明書推奨）
- 署名付きメッセージ（JWS）
- 鍵更新フロー (
GetCertificate,ReplaceCertificate) - セキュリティログのアップロード (
SecurityEventNotification)
5. 移行時の注意点
- 後方互換なし
2.0.1 は 1.6J とメッセージ ID が異なるため、ゲートウェイ や 変換プロキシ が必要。 - 証明書運用
2.0.1 では「CSMS 側の CA で署名された充電器証明書」が必須。証明書の配布・更新手順をあらかじめ整備する。 - ペイロードサイズ
スマート充電プロファイルや ISO 15118 データによりペイロードが大型化。WebSocket フレームサイズ制限に注意。 - エッジ処理
充電器に直接実装が難しい場合、エッジゲートウェイ で 1.6J→2.0.1 変換＋セキュリティ強化を行うことが現実的。
6. どのバージョンを選ぶべきか
| 利用シーン | 推奨バージョン | 理由 |
|---|---|---|
| 既存 1.6J 充電器を運用 | 1.6J 継続 or ゲートウェイ併用 | ハード交換コストを抑える |
| 新規 AC 普及充電器 | 2.0.1 (必須機能のみ) | 将来の ISO 15118 連携が視野 |
| DC 急速＋車両連携 | 2.0.1 フル実装 | プラグ＆チャージ / スマートグリッド連携 |
7. まとめ
- 1.6J が現在も主流 だが、セキュリティ要件・車両連携機能の観点で 2.0.1 へシフト が加速
- 2.0.1 はメッセージ数が約 2 倍。設計段階でモデル化（クラス設計・型定義）しておくと保守が容易
- 移行には 証明書運用とゲートウェイ設計 がキーポイント
次回記事では、OCPP 2.0.1 の「主要メッセージタイプ」を詳しく掘り下げ、実際の JSON 例を使って解説します。