OCPP

OCPP のドライバーの手引き。内蔵のセントラルシステム、充電ポイントの証明書、充電コネクターのタグ、そして Meter、Status、Transaction の名付けの規則。

OCPP のドライバーは、Open Charge Point Protocol を話す EV の充電ポイントに対して、Ganter Lab をセントラルシステムにします。LoRaWAN と同じで、向きが逆です。ステーションのほうから充電器につなぐのではなく、充電ポイントのほうが WebSocket で Ganter Lab につなぎ、自分を登録し、測定値を送り込んできます。

内蔵のセントラルシステムは、有効な OCPP の機器の 1 つ目が動いている connector に読み込まれたときに始まり、最後の 1 つが削除されるか無効になったときに止まります。充電ポイントが 1 つも設定されていなければ、そのポートで待ち受けるものは何もありません。1 つ追加すれば、アプリケーションを再起動せずに戻ってきます。設定する機器 1 台が、1 つの充電ポイントを表し、それがつないでくるときの ID で見分けられます。

充電ポイントの準備

このステーションへつないでくるのは充電ポイントのほうで、出荷時にはステーションがどこにあるかを知りません。OCPP の機器のページにはそれぞれ「充電ポイントの準備」カードがあり、充電ポイントの OCPP 設定に入力する値を、このステーションに合わせて示します。

カードは、ステーションを開いてから充電ポイントが一度も接続していないあいだは開いていて、接続すると折りたたまれます。次に充電ポイントを設定するときのために、ページには残ります。Windows にインストールされたルートが証明書を保証しない充電ポイントは、最初の接続で拒否され、現場設備へのアクセスで待ちます。

ファイルは、充電ポイントが登録されてセントラルシステムが初めて起動したときに書き出され、それまではカードがその旨を示します。このステーションのすべての充電ポイントで同じファイルで、ステーションの名前やアドレスが変わっても変わりません (ステーションのルート証明書を参照)。

以前のバージョンのファイルを渡された充電ポイントには、このファイルを一度インストールする必要があります。 このバージョンの最初の起動時に、以前のファイルを持っている可能性のある充電ポイントがあるステーションでは、その起動のあいだだけ、カードに「このステーションのファイルが変わりました」という通知が出ます。通知は注意喚起であって、手順そのものではありません。すでに充電ポイントがあったステーションでは、カードに通知が出てもいなくても、新しいファイルをすべての充電ポイントに一度インストールしてください。サーバー名を確認する充電ポイントは、それ以降このステーションを受け入れます。

セントラルシステムとポート

待ち受けは必ず TLS です。平文の HTTP の待ち受けは、プロセス内の試験のためだけにある loopback 以外では拒否されます。充電ポイントは自分の BootNotification で登録し（60 秒のハートビートの間隔で答えます）、認可のために差し出されたバッジはすべて受け入れられます。Ganter Lab は充電を観測するのであって、料金や入退場を管理するものではありません。

証明書

TLS の握手のサーバー側は、このステーション自身のルートで署名された証明書を差し出します (ステーションのルート証明書を参照)。充電ポイントは、それぞれクライアントの証明書を差し出さなければなりません。

1. その証明書が、次の 2 つのどちらかで信頼されていること。この Windows の機械の上で、そこにインストールされたルートまで正しい連鎖を組み立てられ、TLS の方針のエラーがないこと。または、このドライバーのページの現場設備へのアクセスで、その証明書そのものを承認してあること（下を参照）。どちらの場合も、有効期間の内側にあることが要ります。検査に落ちた接続は拒否され、どの検査に落ちたかを診断ログが記録します。
2. その主体の一般名か、DNS のサブジェクト代替名が、つないでくるときの充電ポイントの ID を名指ししていること。接続のパスにあるものと違う充電ポイントを名乗る証明書は、承認してあっても拒否されます。

クライアントの証明書のない握手は、データが 1 つも流れる前に落とされます。

ステーションのルート証明書

保存されているルートが開けなくなった場合 (たとえば別の Windows アカウントで書かれたものなど) は、新しいルートに置き換えられます。そのときはすべての充電ポイントに新しいファイルが一度必要で、カードがそれを示します。

現場設備へのアクセス

証明書が自己署名だったり、メーカー自身の認証局が発行したものだったりして、Windows にインストールされたどのルートもその証明書を保証しない充電ポイントでも、そのルートをこのコンピューターにインストールする必要はありません。最初の接続は拒否され、その証明書は、OCPP のドライバーのページの最後にある現場設備へのアクセスで、判断を待ちます。OPC UA のドライバーのページにあるのと同じカードです。

承認するのは証明書 1 つ 1 つで、それに署名した認証局ではありません。そのため、同じメーカーの 2 台目の充電ポイントは、それ自身の承認を待ちます。承認する前に、フィンガープリントを充電ポイントが示すものと照合してください。承認しても、その証明書がどの充電ポイントかは変わりません。受け入れるのは、その証明書が名指す充電ポイントの ID の下だけで、有効期間の内側だけです。Windows がすでに信頼している証明書はこれまでどおり受け入れられ、ここには出ません。何かが自動で承認されることはありません。

判断はステーションのデータフォルダーの ua\pki\ocpp に保存され、再起動しても残ります。操作が描かれるのは Connector を構成できるロールだけで、操作が効くのはステーション自身のウィンドウの中だけです。別の機器のブラウザーはカードを読むだけで変えられず、エージェントのツールが証明書を承認することもありません。一覧に並ぶ承認待ちの証明書は 100 件までです。いっぱいになると、新しい証明書は引き続き拒否されますが一覧には並ばず、カードがそのことを伝えます。

接続の項目

ホスト、ポート、資格情報の項目はありません。接続の詳しいところは充電器が持っていて、このステーションは、その機器がどの充電ポイントを指すのかだけ知っていればよいからです。読み出し周期の項目もありません。OCPP は押し出し型で、充電ポイントが MeterValues と StatusNotification のメッセージを自分の都合で送ってきます。タグは、最後に受け取ったデータから 1 秒の決まった周期で更新されます。

ですから、まだつないできていない充電ポイントや、まだ報告していない充電コネクターには、失敗した読み取りではなく、読み取りがありません。そのタグは空のままで、失敗は診断ログに残りません。充電ポイントがまだ送っていないタグは、プロトコルが働いている姿です。

充電ポイントの稼働状態

充電ポイントは値があるときに送ってくるので、タグが黙っているだけでは、まだ報告していない充電ポイントと、いなくなった充電ポイントを見分けられません。その稼働状態、つまりツリーのその行の点と、ドライバーのページの 稼働状態 の列は、代わりにこのステーションのセントラルシステムへの接続にしたがいます。

充電ポイントがつないでいる間は、まだ報告していない充電コネクターはその状態を下げません。充電ポイントへの変更を保存したあと、または Connector が起動したあと、最大 10 秒間は まだ不明 と読まれます。機器を入れ直すとセントラルシステムが再起動することがあり、充電ポイントがつなぎ直すまで少しかかるからです。

タグ

OCPP のタグは、充電ポイントの充電コネクターを 1 つ読みます（OCPP の意味での connector、つまり 1 か所の差込口で、1 から数えます）。OCPP 2.0、2.0.1、2.1 では、この番号は EVSE の番号です。そこでは充電コネクターが EVSE ごとに 1 から数え直されるためです。タグには 3 種類あり、検証されるタグ名の接尾辞で見分けます。

これらの接尾辞のどれも持たない名前は、検証が拒否します。Connector1Meter、Connector1Status、Connector1Transaction のように名前を付けてください。

OCPP のタグは読み取り専用です。アクセスの項目に書き込める選択肢はなく、書き込みは装われるのではなく拒否されます。充電ポイントに指令を出すのは、次に述べるそれ自身のコマンドであって、タグに書いた値ではありません。

コマンド

充電ポイントは、読むだけでなく指令も出します。OCPP の機器はそれぞれ、下のコマンドを、このステーション自身の OPC UA のアドレス空間で機器のメソッドとして持ちます。ですから、このステーションに接続した OPC UA のクライアントが、そのメソッドを呼ぶことでコマンドを出せます。

どのコマンドも、最初の引数として充電ポイントの ID を取り、その充電ポイント自身の答えを結果として返します。

AttributeType は Actual、Target、MinSet、MaxSet のいずれかです。

TransactionId の出どころ。 RemoteStopTransaction と GetTransactionStatus は、番号で指した 1 つのトランザクションに働きます。その番号は、その充電が行われている充電コネクター（OCPP 2.x では EVSE）の Transaction タグ、たとえば Connector1Transaction から読み、読んだとおりに渡してください。そこが空の文字列なら、その充電コネクターではトランザクションが走っていません。

どのバージョンでも同じコマンド一覧。 充電ポイントがどのバージョンを話していても、コマンドは上の名前のままで、ステーションはそのバージョンが定める形でそれぞれを送ります。OCPP 2.0、2.0.1、2.1 では充電コネクターが EVSE の下にまとめられており、ConnectorId として渡した番号は EVSE を指します。

答えを待つこと。コマンドは、ステーションが送った時点では終わっていません。ステーションは、送ったまさにその指令に充電ポイントが答えるまで呼び出しを開いたままにし、それを一緒に運ばれる対応付けの識別子で突き合わせ、そのときはじめて成功を伝え、答えを返します。それ以外の終わり方は 3 つで、どれも理由を添えた失敗として伝えられます。

• 充電ポイントがつながっていない、あるいはその接続が開いていない。何も送られません。
• 充電ポイントが OCPP のエラーで答えた。たとえば、実装していないコマンドです。そのエラーコードが理由になります。
• 答えがまったくないまま 30 秒が過ぎた。誰も答えなかったコマンドは失敗であって、決して成功ではありません。

機器が持っていない充電ポイントや、つながっていない充電ポイントに対して出したコマンドは、待ち行列に入るのではなく、その場で拒否されます。

機器検出

OCPP のドライバーの機器検出は、セントラルシステムに今つながっている充電ポイントを並べ、候補のチャネルを読むと、その充電ポイントがこれまでに報告した充電コネクター 1 つにつき Meter、Status、Transaction のタグを 1 つずつ提案します。

最初の充電ポイントは必ず手で設定します。セントラルシステムが待ち受ける前は何もつなげませんし、待ち受けるのはここに OCPP の機器ができてからです。ですから、充電ポイントを 1 つも設定していない設備をスキャンしても何も見つからず、そう伝えます。その最初の機器は、充電器がつないでくるときの ID で追加してください。そのあとは、つないできた充電器を機器検出で見つけられます。機器検出の全体の流れは Connector のページにあります。

ID は、証明書でも、接続のパスでも、機器との突き合わせでも、大文字と小文字を問わずに照合します。CP-A を名乗る証明書を持って cp-a としてつないでくる充電器は、識別子が CP-A と書かれた機器と同じ充電ポイントです。

すでにある充電ポイントは、自分のページから充電コネクターを読み直せます。「タグ」のカードの見出しにあるタグ検出は、つながっているあいだに報告した充電コネクターごとの Meter、Status、Transaction のタグのうち、機器にまだないものを出します（機器のタグを検出するを参照）。