OCPP
OCPP（Open Charge Point Protocol）は、電気自動車（EV）用充電設備とバックエンドの管理システム（CSMS: Charge Station Management System）を接続するための通信プロトコルである。充電スタンド側の稼働状況監視、認証、課金、遠隔制御、ファームウェア更新、スマート充電など、運用に必要な機能を標準化し、メーカーやベンダーの相互運用性を高める目的をもつ。車両‐充電器間の通信を扱うISO 15118や、事業者間ローミングを扱うOCPIと役割が異なり、OCPPは「充電スタンド―クラウド」の管理面に特化する。
位置づけと基本概念
OCPPの典型構成は、充電スタンド（Charging Station/旧称Charge Point）とCSMSのクライアント‐サーバ型である。スタンドは起動時にブート通知を行い、状態・計測値を周期送信し、CSMSは遠隔操作や設定変更を行う。設備内はEVSE（個別給電口）とコネクタの階層で表現し、トランザクション（充電セッション）単位で開始・終了・計測・課金の文脈を保持する。IDトークン（RFID、アプリ等）や契約IDを用いた認証が中核である。
歴史とバージョン
OCPP 1.5は主にSOAPを用いた初期普及版である。1.6ではJSON over WebSocket（通称1.6J）が主流となり、RemoteStart/Stop、MeterValues、SetChargingProfileなど実運用で重要な機能が成熟した。2.0/2.0.1ではデバイスモデル、トランザクションの再設計、セキュリティと証明書管理、拡張的なスマート充電が強化され、将来の双方向給電（V2G）や高機能UI、AC/DC急速器の多様性に対応しやすくなった。
通信形式とメッセージモデル
OCPP 1.6J/2.0.1はいずれもWebSocket上のJSONフレーミングを採用する。基本的に「要求（CALL）」「応答（CALLRESULT）」「エラー（CALLERROR）」の3種で、要求は一意IDとアクション名、ペイロードを持つ。例として、要求は配列形式[2,”uniqueId”,”Action”,{…}]、応答は[3,”uniqueId”,{…}]、エラーは[4,”uniqueId”,”ErrorCode”,”Description”,{details}]のように表現される。双方向の非同期処理であり、時刻同期、リトライ、順序制御が設計上の要点となる。
主要ユースケース（1.6系）
- BootNotification：起動時の機種情報・ベンダ情報の登録と稼働許可取得
- Heartbeat：生存監視と接続維持
- StatusNotification：コネクタ占有、故障、準備完了などの状態遷移通知
- Authorize：ユーザIDトークン認証
- StartTransaction/StopTransaction：充電セッションの開始・終了とメータ値確定
- MeterValues：電力量・電圧・電流などの周期計測送信
- Firmware/Diagnostics：遠隔更新、ログ収集、再起動等の保守
- SetChargingProfile/ClearChargingProfile：時刻帯・電流上限による負荷平準化
2.0/2.0.1での再設計点
OCPP 2.0.1では、トランザクション関連がTransactionEventに集約され、開始・測定・中間イベント・終了が一貫管理される。Device Modelにより、機器の構成要素や変数（例：コンポーネント名・変数名・アクセス権）が標準化され、GetVariables/SetVariables、GetBaseReport/NotifyReportで装置状態を構造的に取得できる。UI機能（DisplayMessage）やイベント通知、予約やローカル認証リストの扱いも拡充され、現場の可用性と保守性が向上する。
スマート充電と需要応答
OCPPは系統や施設の需要抑制に用いられる。1.6ではSetChargingProfileでEVSE/コネクタごとの電流上限・スケジュールを適用し、群管理でピークカットを実現する。2.0.1ではNotifyChargingLimit、ChargingNeeds、SetChargingProfileの連携で、車両要求（必要エネルギー・出発時刻等）と系統制約（トランス容量・契約電力・太陽光余剰など）を調停し、柔軟な配電最適化につなげられる。
セキュリティと証明書管理
OCPP 2.0.1はTLSベースの相互認証を前提とし、クライアント証明書の導入・更新・失効管理をプロトコルで支援する（InstallCertificate、GetInstalledCertificateIds、DeleteCertificate、CertificateSigned等）。セキュリティイベント通知（SecurityEventNotification）やログ収集、署名付きメータリングの取り扱い強化により、改ざん耐性や監査性を高める。鍵保護やブート時の信頼連鎖、ポリシー準拠の運用が実装の勘所である。
デバイス管理と保守運用
OCPPは遠隔設定（SetVariables）、構成の可視化（GetBaseReport/NotifyReport）、診断（GetLog）、更新（UpdateFirmware）等を規定する。現場ではネットワーク不安定や一部コンポーネント故障に備え、キューイング、再送、部分適用、ロールバックを考慮した設計が重要である。ローカルフォールバック（オフライン時の認証キャッシュや制限運転）も信頼性向上に寄与する。
相互運用性と適合性試験
OCPPは相互運用性が価値の中心である。ベンダ横断の適合性テスト、プロファイル（必須/任意機能集合）の明確化、負荷・遅延・ロス条件を含むストレス検証が不可欠である。CSMSと充電スタンド双方で、バージョン/サブプロトコルの合意、機能交渉、エラーハンドリング（未実装アクション、スキーマ不整合、タイムアウト、重複要求）を確実に実装することが、現場混在環境での安定運用につながる。
設計指針（実装の勘所）
- メッセージ冪等性：再送時に重複トランザクションや二重課金を防ぐため、ユニークIDと状態機械を厳密に管理する。
- 時刻基準：NTP等でUTC同期し、メータ時刻とイベント時刻の一貫性を担保する。
- バッファリング：通信断に備え、測定値・イベントを容量制限付きでバッファし、再接続時に順次送信する。
- 構成管理：Device Modelの変数をスキーマ化し、監査可能な設定変更ログを残す。
- セキュア更新：ファーム更新は署名検証・段階展開・フェイルセーフを徹底する。
- 性能とスケール：多数EVSE同時制御に備え、非同期I/O、バックプレッシャ、優先度制御を設計に含める。
関連規格との関係
OCPPは車両側規格のISO 15118（Plug & Chargeや電力協調）と補完関係にあり、事業者間ローミングのOCPIとは適用レイヤが異なる。上位の事業システムはOCPIで契約・料金連携を行い、現場のデバイス運用はOCPPで統制するという役割分担が一般的である。施設側の需要制御や分散電源との協調では、エネルギー管理システム（EMS）とOCPPのスマート充電機能を連携させる設計が実務上有効である。