ビークルプロトコルとバックエンドプロトコル:2つの別々のスタック

充電器が交わらない2つの会話の間に置かれます。一方では、どれだけの電流を流すか、誰が支払うかを車両に伝えています。もう一方で、バックエンドとセッション、メーター、リモートコマンドと通信します。両者は異なるプロトコル、異なるデータモデル、異なる認証制度を使用しています。

買い手は常に両者を混同し、その混同は調達における最も高価な誤解を生み出します。例えば、プラグ&チャージを提供すると信じて現代的なバックエンドプロトコルを必要とする仕様や、請求の問題を解決するために期待される車両アップグレードなどです。レイヤーを分けることで、各要件が個別にチェック可能になります。

2つのスタック、2つのジョブ

下のスタックは充電ケーブルの上を通っています。物理的な接続、電源投入前の安全チェック、充電パラメータの交渉、そして後期バージョンでは車両の識別や自動認可を可能にする証明書交換も管理します。

上部スタックは通常モバイルデータまたはサイトLANのネットワーク接続上で動作します。オペレーターが必要とするもの、すなわち開始・停止コマンド、取引記録、メーター値、診断、ファームウェア管理、設定などが含まれます。車両の直接的な映像は見られません。セッションについて知っていることはすべて、充電器から学んだものだ。

その非対称性こそがこのテーマ全体の鍵です。充電器は独自の意見を持つ翻訳器であり、透明なパイプではありません。バックエンドが記録するものは、充電器が報告することを選択したもので、上位プロトコルが定義する形式です。

車両と充電器の間で

古い配置はシンプルで、今でも汎用的な代替手段です。制御パイロットのパルス幅変調信号が最大電流を伝え、車両は電圧レベルを変えて応答し、シーケンスが許すと充電器はコンタクターを閉じます。現代的な意味でのデータチャネルやアイデンティティ交換は存在しません。承認はプロトコルの外で行われ、カードリーダー、アプリ、または手動リリースを通じて行われます。

高レベルプロトコルはデータチャネルを追加します。ISO 15118およびその前身DIN 70121は、電力線通信による構造化された通信を行っています。車両が自己識別し、双方が能力を交換し、車両が欲しいものを伝え、充電器が供給可能な電力を報告します。交換はセッション中ずっと続くため、充電器は電流だけでなく車両の要求も確認できます。

後のISO 15118版では、これを証明書ベースの識別に拡張し、自動承認を可能にするものと双方向のエネルギー転送にも応用されています。どちらの拡張機能も、従来のバージョン専用の充電器にはないハードウェアとソフトウェアを必要とします。

このレイヤーは車両の特性がシステムに入る部分です。また、充電器自身のドキュメントには通常、車両に対してどの高レベルプロトコルを伝えているか、どのバックエンドプロトコルを上位に伝え

Chargerとバックエンドの間で

ここで支配的なプロトコルはOCPPであり、業界団体によって維持され、充電器メーカーやバックエンドプラットフォームによって独立して実装されたオープンスタンダードです。認証、トランザクション開始・停止、メーターの数値、ステータス通知、リモートコマンド、ファームウェアの更新および設定のメッセージを定義します。

後のOCPPバージョンではデバイス管理、スマート充電プロファイルの改善、コンポジットスケジュールのより構造化されたアプローチが追加されました。オペレーターにとっての実質的な違いは、バックエンドが各コネクターの充電時間や速度をどれだけコントロールできるか、そしてそのどれだけを現地訪問なしで変更できるかにあります。

OCPPがしないのは車両と通信することです。最新バージョンをサポートするバックエンドは、車両の情報を間接的に学びます。充電器が値を報告しなければ、バックエンドはそれを表示できず、どんなに高度なプラットフォームでも復元できません。

コンプライアンスはさらに混乱を招きます。OCPP準拠は、定義されたバージョンに対して充電器の認証であり、その認証はその製品とそのバージョンに属します。車両側のプロトコルについては何も書かれていませんし、特定のバックエンドが同じバージョンをどれだけうまく実装しているかについては何も言っていません。適合製品2つでも仕様のオプション部分で相互運用に失敗することがあるため、統合テストは別の活動として存在します。

なぜプラグと充電は両面を必要とするのか

自動認可は通常「プラグ&チャージ」と呼ばれ、機能ではなくチェーンです。車両は高レベルプロトコル上の契約証明書を提示します。チャージャーは信頼する証明書チェーンと照らして検証し、ローカルで認可するか、決定のために身分を上位に転送します。バックエンドは契約が有効で請求可能であることを確認しています。

すべてのリンクが存在する必要があります。契約証明書がない場合は、車両は証明書を提示できません。高レベルプロトコルやトラストストアがない充電器はそれを読み取ることができません。対応する証明書処理がないバックエンドでは、それを解決することはできません。リンクが欠けている場合、セッションはカードやアプリ、QRコードに切り替わります。これは自動充電を宣伝し、一部の車両と運転者の組み合わせのみに提供されるネットワークでドライバーが経験するものです。

これがこの機能が実際には不均一に利用可能になる理由でもあります。これは、3つの独立して更新されたシステムの交差点に依存しており、その交差点はどれよりも小さいのです。

一方をアップグレードしてももう一方はアップグレードされません

同じ理由で4つの一般的な仮定が失敗します。

新しいバックエンドプロトコルが自動認可を提供します。しかし、承認は下のスタックで移動するため、そうではありません。充電器は最新のバックエンドバージョンを通信してもカードが必要です。

自動充電対応の車両はどのネットワークでも動作します。充電器とバックエンドがそれに合わせて設定され、運転者が車両のプロバイダーとローミングまたは契約関係にある

充電器のファームウェアアップデートにより車両側の機能が追加されます。充電器側の会話は更新可能です。充電器からは車が動かせません。

そしてその認証は両方をカバーしています。認証は製品ごと、プロトコルごと、バージョンごとに発行され、ある層の名前を冠した証明書はもう一方について何も言いません。

よく仕様化された充電器は2つのレイヤーを別々に明記しており、このレンジの製品は通常、サポートする車両側プロトコルとともにバックエンドプロトコルバージョンを記載しています。120 kWと180 kWの局仕様はこれに対応しており、この分離が両要件を個別に検証可能にしています。

これを要件に書く方法

テストできない要件は要件ではありません。4行でテスト可能です。

充電器がサポートすべき車両側のプロトコルとエディション、そしてそのインターフェースで自動認可が必要かどうかを記載します。バックエンドのプロトコルとバージョン、そして適合性を認証する必要があるのか単に宣言する必要があるのかを明記してください。どちらかの交渉が失敗した場合のバックアップの挙動を明示してください。なぜなら、サイトが静かに認証されていないモードに移行すると収益の問題になるからです。そして、どの証拠が認められているかを明記してください:証明書番号、テストレポート、または運用者が使用するプラットフォームとの共同テストです。

その最後のものがほとんどのプロジェクトを捉えます。適合性試験は、製品が仕様に合致していることを証明します。統合テストは、2つの製品が共存していることを証明しています。調達書類はしばしば前者を求め、後者が必要とされ、そのギャップはハードウェアが納品されてから明らかになります。

これらのプロトコルと負荷管理の関係は非常に密接で混乱を招くほどです。バックエンドプロトコル上で提供されるスマート充電プロファイルは、充電器への命令であり、充電器は車両が受け入れる範囲内でそれを尊重しなければなりません。このやり取りはload managementの注記で扱われており、命令の終わりと車両の限界の始まりを説明しています。

ほとんどのオペレーターにとって、実用的な結果は再設計ではなくチェックリストです。2つのプロトコル要件を別々の行に書き、それぞれのバージョンを指定し、交渉が失敗した場合にどうなるかを尋ね、最初の苦情の後ではなくサイト開設前に組み合わせをテストしてください。