バックエンドが止まったら、充電器は全台止まるのか? 充電器オーナーが「OCPPエンドポイントのフォールバック」で本当に求めていること

月曜の朝6時を想像してください。どの拠点にも異常はありません。充電器には電源が入り、4G回線もつながり、ケーブルも問題なし。ところが、夜間に行った充電管理システムのサーバー変更、あるいは証明書の期限切れ、あるいはクラウドリージョンの不調によって、すべての充電器が接続に失敗します。ダッシュボードは真っ赤。到着したドライバーが操作しても、充電は始まりません。

オーナーから「OCPPエンドポイントのフォールバックが欲しい」と相談されるとき、頭にあるのはこの場面です。最初のアドレスが使えなくなったときに、充電器が接続しにいける二つ目のアドレス。バックエンド一か所の不具合で全拠点が同時にオフラインになる事態を避けたい、ということです。

一つの機能のように聞こえますが、実際には三つの別々の問題です。まず、それを切り分けるところから始めます。

「フォールバック」と呼ばれる三つのこと

	何が止まったか	影響範囲	参照先
拠点の回線断	充電器がインターネットに出られない	その拠点のみ	OCPP 1.6Jのオフライン動作とローカルCSMSプロキシの記事(英語)
バックエンド/エンドポイント障害	充電器はネットに出られるが、CSMSのアドレスが応答しない、または正しく応答しない	そのアドレスを向く全充電器	本記事
事業者の切り替え	別のCSMSへ移行したい、または並行運用したい	ネットワーク全体	後半で簡単に触れます

オーナーはこれらを一括りにしがちです。症状はどれも「赤い点」だからです。しかし、対処は同じではありません。

オーナーから聞く悩み

よく聞くものを、おおよその順に挙げます。

アドレスが一つしかなく、単一障害点になる。 充電器ごとにCSMSのURLは一つ。そこが使えなくなれば、試せる先がありません。

現場に誰もいない。 ファームウェアによっては、新しいURLを受け付けるのが、まさに止まっているシステムからだけ、ということがあります。復旧に拠点ごとの技術者派遣が必要になったり、メーカーしか操作できないポータルに頼ることになったりします。

課金記録が失われる、または乱れる。 障害中のセッションは充電器が保持し、後から送信する必要があります。復旧したバックエンドの規則やトランザクション番号の振り方が違うと、セッションの重複や欠落が起きえます。

決済が止まる。 QRコードとPromptPayまたはQR30で支払うドライバーは、バックエンドによる入金確認が必要です。バックエンドがなければ、充電器がどれほど優秀でもそのセッションは始まりません。

ロックイン。 特定ベンダーのバックエンドに縛られた充電器では、乗り換えも、一部の充電器で他のプラットフォームを試すことも現実的にできません。

再接続の集中。 バックエンドが復旧した瞬間、数百台が一斉に再接続を試み、回復途中のシステムが再び倒れます。

なぜOCPPでは難しいのか

OCPPは、一台の充電器と一つのCSMSの間のプロトコルです。接続した後に双方が何を話すかは定めていますが、どのアドレスをどの順に試すかについては、ほとんど定めていません。

OCPP 1.6J。 私たちの知る限り、仕様には予備エンドポイントの一覧は定義されていません。CSMSのアドレスは充電器自身の設定にあり、多くはベンダー固有の項目です。二つ目のアドレスに対応するかどうかは、ファームウェア次第です。Open Charge Allianceの稼働率向上ガイドはオフライン時の動作を詳しく扱っていますが、複数のバックエンドURLやCSMSフェイルオーバーは扱っていません。

OCPP 2.0.1。 充電器に接続プロファイルを保持する仕組みが加わりました。CSMSはSetNetworkProfileメッセージで、CSMSのアドレスとセキュリティプロファイルを含む接続プロファイルを、充電器の番号付き構成スロットに置けます。仕様には、充電器を新しいCSMSへ移行するユースケースもあります。これで充電器は複数の接続先を持てますが、どう選び、いつ切り替えるかはベンダーに確認が必要です。日本を含め、現場にある充電器の多くはまだ1.6Jなので、2.0.1の経路を当てにすることはできません。

実務上の結論として、設置済みの充電器の大半では、フォールバックはプロトコルの中ではなく、充電器の周囲に設計することになります。

フォールバックを置ける四つの層

flowchart TD
    A["充電器"] --> B["第1層 ファームウェアの予備URL"]
    A --> C["第2層 固定のホスト名"]
    C --> D["主CSMS"]
    C --> E["待機CSMS"]
    A --> F["第3層 拠点のローカルプロキシ"]
    F --> C
    A --> G["第4層 充電器のオフラインモード"]

第1層: 充電器内の予備URL。 ファームウェアが二つ目のエンドポイントに対応していれば、それを使います。最も単純で、完全にメーカー側の機能です。購入前に確認し、頼る前に試験してください。

第2層: 固定のホスト名を一つ決め、その裏でフェイルオーバーする。 充電器は、自社が管理する一つの名前だけを向きます。その裏側でDNSやロードバランサーが正常なバックエンドへ接続を振り分け、待機系は充電器に一台も触れずに引き継げます。URLを一つしか持てない充電器でも使えます。代わりに、名前、証明書、ヘルスチェックを自分で持つことになります。

第3層: 拠点のローカルプロキシ。 拠点のネットワークに置く小さなサービスが、充電器の通信相手を近くに保ち、メッセージを溜め、バックエンドに届くときに転送します。バックエンドの一覧を持たせることもできます。遠隔地や停止コストの高い拠点で最も効果的ですが、更新と監視の対象が増えるため、拠点ごとに判断します。

第4層: 充電器自身のオフラインモード。 他がすべて失敗しても、既知のドライバーは充電でき、記録は後で送れるようにしておきます。これは最後の砦であり、他の層の代わりではありません。

フォールバックで解決しないこと

「URLをもう一つ足すだけ」と言う人には注意してください。

• 二つのバックエンドが同じ情報を持つ必要がある。 充電器台帳、RFID一覧、料金、認証情報が揃っていない待機系は、充電器を拒否するか、誤って課金します。
• 一台の充電器に二つの司令塔を置かない。 二つのバックエンドが同じ充電器を自分のものだと思うと、トランザクション番号の重複や命令の衝突が起きます。どちらが有効か、引き継ぎをどう宣言するかを決めておきます。
• 証明書と認証情報は充電器に付いてくる。 待機系は、充電器が期待する名前に対する有効な証明書を持ち、同じ充電器IDとパスワードまたは証明書を受け付ける必要があります。
• 再接続にはペース配分が要る。 OCPP 2.0.1の充電器では、Open Charge Allianceはバックオフ設定を調整し、最小待ち時間を短く、ランダム幅を広くして、全台が一斉に戻らないようにすることを勧めています。
• 決済は別の依存先。 QRとPromptPayのセッションは、OCPPだけでなく入金確認の経路にも依存します。
• オフライン時の未登録ユーザー充電にはコストがある。 誰でも充電できるようにするのは、オーナーが負うリスクです。OCAのガイドでは、AC充電器では許容されることが多い一方、DC急速充電器ではリスクが大きすぎることが多いとされています。

充電器ベンダーとCSMS事業者に確認したいこと

質問	重要な理由
ファームウェアは二つ目のCSMS URLを受け付けるか。どう選ぶか	第1層があるかが決まる
URLは遠隔で変更できるか、現地作業のみか	バックエンド障害時のコストが決まる
OCPPのバージョンは何か。2.0.1ならSetNetworkProfileに対応するか	取れる選択肢が決まる
溜まったトランザクションをどれだけ保持し、再送するか	課金記録を守る
接続失敗後のバックオフ設定はどうなっているか	再接続の集中を避ける
自社管理のホスト名とTLSで接続できるか	第2層を可能にする
待機CSMSは同じ充電器、タグ、料金データを取り込めるか	待機系を実効的にする
この機種でフェイルオーバーを試験済みか	唯一意味のある証拠

現在提供しているものと、プロジェクト対応のもの

両者は分けて説明します。

現在プラットフォームに含まれるもの: OCPP 1.6Jエンジン、アップグレード経路としてのOCPP 2.0.1、バックアップと復旧訓練を含むマネージドホスティング、稼働監視とオンコール体制、通信が不安定な拠点向けのローカルCSMSプロキシという選択肢。

案件ごとにスコープを決めるもの(すぐ入れられるスイッチではありません): お客様のバックエンドの前段に置く固定ホスト名とフェイルオーバーの設計、待機系の構成と必要なデータ同期、お客様の充電器群に対するバックオフと再接続の見直し、運用中の機種ごとの、コミッショニング時のフェイルオーバー試験。

お約束できないこと: すべての充電器機種が予備URLに対応していること。これはファームウェアの問題でベンダーごとに異なります。確認はデータシートではなく試験で行います。

すでに充電器を運用していて、どの程度リスクがあるか知りたい方は、充電器のメーカーと機種、OCPPバージョン、CSMSアドレスの設定方法、拠点数を、件名「OCPP fallback review」でhello@simplico.netまでお送りください。48時間以内にスコープの概要をご返信します。LINE(iiitum1984)でもご連絡いただけます。

よくある質問

全充電器に二つ目のURLを足すだけではだめですか?
ファームウェアが対応していれば可能です。OCPP 1.6Jには標準の予備一覧がないため、多くの充電器はアドレスを一つしか受け付けません。固定ホスト名とその裏のフェイルオーバーが、一般的な回避策です。

OCPP 2.0.1で解決しますか?
助けにはなります。充電器が複数の接続プロファイルを持てるからです。ただし、お使いの充電器がどう選ぶかは確認が必要で、現場の多くはまだ1.6Jです。

バックエンド停止時に進行中のセッションはどうなりますか?
充電器は通常、承認済みのセッションを続行し、メッセージを溜めて後で送ります。新規セッションの扱いは、オフライン設定とドライバーの支払い方法によります。

QRやPromptPayの決済も守れますか?
フォールバックだけでは守れません。これらのセッションは入金確認に依存するため、接続依存のものとして計画してください。

ローカルプロキシは予備のCSMSと同じですか?
違います。プロキシは一つの拠点のために溜めて転送します。予備のCSMSは、全台を引き継げる二つ目の中央システムです。両方を組み合わせる設計もあります。

充電器を変更する必要がありますか?
多くの場合、不要です。最も一般的な設計では、充電器には触れず、すでに使っているアドレスの裏側を変えます。

この記事の発信元は?
タイのソフトウェアエンジニアリングスタジオ、Simplicoです。タイと東南アジアの事業者向けに、EV充電プラットフォームを構築・運用しています。

関連記事

• What an EV Charger Does When the Internet Drops: OCPP 1.6J Offline Behaviour and Where a Local CSMS Proxy Fits
• How to Build an EV Charging Network Using OCPP: Architecture, Technology Stack and Cost Breakdown
• Scoping an EV Charging Platform for a Large Property Owner
• Simplico EV充電プラットフォーム(CSMS)
• Improving uptime with OCPP, Open Charge Alliance