PV-
Dashboard

3つのポータルではなく、1つの画面

太陽光発電設備の運転データは、3つの場所に分散していました。2台のパワーコンディショナはそれぞれ独自のWeb画面を持ち、電力量計の値はHomematicの建物制御システム内にあり、気象情報はどこにもありませんでした。発電量・自家消費量・売電量を把握するには、3つのソースを個別に開き、頭の中で計算する必要がありました。

本ダッシュボードは、すべてのデータをサーバー側で収集し、共通のデータモデルに正規化したうえでREST APIとして提供することで、この問題を解決します。その上にReactによるフロントエンドを構築し、社内ネットワークのブラウザから利用できるようにしました。インストール不要、ベンダーアカウント不要、データが社外に出ることもありません。

機器と話すのはバックエンドだけ、フロントエンドはAPIとだけ

本プロジェクトは、要件定義、機器インターフェースの解析、データモデルの設計、バックエンド・フロントエンドの実装、運用まで、すべて単独で担当しました。同僚には個別の技術的な質問について随時相談しましたが、アーキテクチャ、技術選定、実装の判断は一貫して自分が行っています。

地味な作業も含まれます。各機器がどのエンドポイントを提供しているのか、どの形式・どの周期で応答するのか、そして応答がない場合に何が起きるのか。それらを一つずつ確認するところから始めました。

未経験の技術スタック。 私の専門はシステム管理であり、アプリケーション開発ではありません。Node、React および周辺ツールは本プロジェクトの中で独学で習得しました。当初から目標は試作品ではなく、実運用に耐えるシステムでした。

構成

3つの時間粒度を一つの軸に

3つのインターフェース、3つの異なるデータ形式。 HTTP経由のCSV、建物制御システムからのXML、公開気象APIのJSON。いずれも本用途を想定して設計されたものではなく、共通の規約もありません。実際の労力は取得ではなく、フロントエンドが例外処理なしに扱える形へ正規化する部分にありました。

時間粒度の不一致。 現在値は秒〜分単位、パワコンの集計値は日・月・年単位、気象予報は時間単位です。これらを一つの時間軸上に並べるには、タイムゾーンと夏時間切り替えの厳密な処理が欠かせません。処理を誤ると、年に2日だけ欠測や重複が発生し、通常のテストでは発見できません。

機器は常に応答するとは限らない。 パワコンは夜間に有効な値を返さず、CCUは再起動時に一時的に応答しなくなります。一つのソースの障害が他の表示を巻き込まないよう、共通の障害経路ではなく、ソースごとの耐障害設計としました。

異常は精算時ではなく、その場で見える

単なる数値表示ではなく電力量計のロジック。 自家消費率や自給率は、昼間／夜間電力量計、売電量計、瞬時系統電力から、符号を正しく扱い、積算値と瞬時値を明確に区別して初めて導き出せます。符号の誤りは結果が一見もっともらしく見えるため、特に厄介です。

機器への負荷を抑える。 ブラウザからのリクエストが、そのまま機器への問い合わせになってはいけません。バックエンドが一定周期で収集し、キャッシュから配信する構成とすることで、開かれているダッシュボードの数に関係なく、パワコンとCCUへの負荷を一定に保っています。

• 異常の早期発見。 発電量の落ち込み、ストリングの故障、パワコンの停止が、次回の精算時ではなく即座に可視化されます。
• 気象予報による裏付け。 発電量が少ない日も予報と照合でき、日射量不足によるものか実際の故障かを切り分けられます。

クラウド不使用、ライセンス費用ゼロ、拡張できる基盤

• 3つのポータルが1つの画面に。 発電量、買電量、売電量、自家消費量を初めて一画面に並べました。「設備は想定どおり稼働しているか」という問いに、数回の画面遷移ではなく数秒で答えられます。
• クラウド不使用、ライセンス費用ゼロ。 すべてのデータは社内ネットワーク内に留まります。ベンダーポータルへの依存も、継続的な費用も発生しません。
• 拡張可能な基盤。 REST APIは独立したインターフェースとして設計しており、フロントエンドに手を加えることなく、追加の分析・エクスポート・他システム連携に対応できます。