Amazon Web Services ブログ

IoT TwinMaker Knowledge Graph でビルのメンテナンスコストを削減する

この記事は Reduce building maintenance costs with AWS IoT TwinMaker Knowledge Graph を翻訳したものです。

はじめに

オフィスワークからハイブリッドおよびフルリモートワークへの移行は、商業ビルの所有者に収益と評価上のプレッシャーをもたらしています。そのため、ビルマネージャーは、最高のテナント体験を提供しつつ、メンテナンスコストを削減することで経費を最適化する方法を模索しています。

ビルマネージャーは、メンテナンスおよびテナントに快適なスペースを提供するという両方のコストをバランスよく管理する必要があります。彼らは多くの場合、複数の物件を管理しています。メンテナンスクルーは、すべての建物に物理的に立ち会っているわけではなく、整備が必要な建物に精通しているわけでもありません。したがって、トラブルシューティングや根本原因の特定に適切なツールを使用することで、メンテナンスの効率を向上させることができます。

建物のメンテナンスは、通常、テナントから報告された問題やアラームに応じてリアクティブに行われます。HVAC メンテナンスおよびエネルギー節約レポートでは、HVAC システムの非リアクティブメンテナンスにより、運用コストを 10% ～ 20% 削減できると記載されています。定期的なサービスのスケジュール設定は簡単ですが、センサー、エコノマイザ、または長い間忘れられていたオーバーライド設定の問題を検出するには、データ主導型のソリューションが必要です。積極的なビルマネージャーは、問題が発生する前に問題を特定します。これには、建物を検索し、同様の状況または障害モードにある機器を特定する効果的な方法が必要です。

このブログでは、Cognizant の 1Facility ソリューションに関する以前の投稿で使用したユースケースを詳しく説明し、AWS IoT TwinMaker の新機能である TwinMaker Knowledge Graph によって問題の発見とトラブルシューティングが簡単になる方法を示します。以前の記事で、Cognizant は AWS IoT TwinMaker を使って顧客向けに建物を視覚化し、複数のデータソースを 1 か所に統合することで付加価値を高める方法について説明しました。建物の管理者は、建物、部屋、設備、および各部屋の位置と使用可能なセンサーを知っていると仮定しました。このブログでは、建物内の HVAC 問題のトラブルシューティングのユースケースについて説明します。お客様が TwinMaker Knowledge Graph を使用してアラームをコンテキスト化する方法を説明し、ビルマネージャーがインサイトを生成できるようにする方法を示します。

ユースケースのウォークスルー: テナントが不快な状況のトラブルシューティング

この例では、ビルマネージャーは自分が管理する建物の 1 つだけに焦点を当てます。入居者から、room 1.1E に不快な環境があるとの報告がありました。特に、部屋が高温で湿度が高いとの報告がありました。

このビルのデジタルツインから、ビルマネージャーは、このビルが東西方向に配置された、1 フロアに 2 つの HVAC ゾーンがある複数階建てのビルであることを知りました。次に、ビルマネージャーは、建物内のすべての室温を表示するダッシュボードを調べ、room 1.1E の温度が設定値よりも高いことを確認します。建物の管理者は、この部屋の湿度センサーデータを分析して、部屋も湿度が高いという報告を裏付けています。

ビルマネージャーはこの建物に詳しくなく、なぜ 1 つの部屋だけが温度と湿度が高いのか戸惑っています。さらに詳しく調べるために、ビルマネージャーはデジタルツインダッシュボードを使用して、room 1.1E が配置されている東 HVAC ゾーンの部屋を調べます。東 HVAC ゾーンの各部屋のセンサーデータを調べたところ、東 HVAC ゾーンの他のすべての部屋は、設定温度よりも低く、予想よりも乾燥していることがわかりました。建物の 3D モデルを調べたところ、建物の管理者は、room 1.1E には窓がないため、他の部屋とは異なっていることに気付きました。彼らは東 HVAC ゾーンの近くの部屋を訪問し、仮説を検証します。また、他の部屋の居住者が部屋を快適にするために窓を開けていることもわかりました。外気により部屋の温度と湿度が設定値を下回りましたが、建物の監視システムでアラームをトリガーするには不十分でした。


現在、東側の HVAC ゾーンには、room 1.1E に異常な状態の問題があることは明らかです。問題の根本原因を突き止めるために、彼はデジタルツインダッシュボードを使用して東の HVAC ゾーンのセンサー値を検査しました。ビルマネージャーは、東部 HVAC ゾーンのすべてのセンサーデータを表示するビューを選択します。彼は、1階の還気温度、2階の還気温度、給気温度、外気温と湿度などのセンサー（時系列データ）からの測定値、および必要なファン速度、エコノマイザの位置、各フロアのダンパー位置などのその他の制御値を検査します。これらのデータポイントすべてにアクセスすることで、ビルマネージャーは傾向を比較し、異常な行動を特定できます。そこで彼は、エコノマイザコマンドを変更しても給気温度が変化しないことに気付きました。これは、エコノマイザが故障していて、外気が建物にリサイクルされる前に還気と混合されていないことを示しています。

次に、ビルマネージャーは履歴データをスキャンして、エコノマイザがいつ故障し始めたかを特定します。これで、ビルマネージャーは、システムを保守している HVAC 会社に修理注文を提出する前に、エコノマイザの問題の詳細を把握できるようになります。これらの洞察により、問題の診断にかかる時間が短縮され、解決までの時間が短縮されます。フォローアップとして、彼はこの建物や自分が管理する他の建物にある他の HVAC ユニットのエコノマイザの状態を積極的にチェックしています。これらの措置は、潜在的なテナントの快適性の問題を軽減するだけでなく、他のエコノマイザの問題が特定され、積極的に修復された場合に、HVAC システムの運用コストを削減するのにも役立ちます。これがプロアクティブメンテナンスの価値です。

TwinMaker Knowledge Graph を使用したテクニカルインプリメンテーション

TwinMaker Knowledge Graphは AWS IoT TwinMaker の新機能です。既存の AWS IoT TwinMaker のお客様は、AWS コンソールの設定ページで標準料金プランを選択することでこの機能を有効にします。すべての新規顧客はデフォルトで標準価格プランを利用し、TwinMaker Knowledge Graph が有効になっています。この機能により、ユーザーは SQL に似た構文のオープンソースの PartiQL クエリ言語を使用してクエリを実行します。顧客はリレーションシッププロパティを使用して、エンティティ同士が物理的または論理的にどのように関連しているかを記述します。その後、ワークスペース内のエンティティとこれらのエンティティ間の関係をクエリできます。たとえば、顧客は名前に「temperature」を含むすべてのエンティティをクエリしたり、対象のエンティティに関連するすべてのエンティティを検索したりできます。これらの機能により、顧客はダッシュボードを作成して同じタイプの機器の性能傾向を1つのサイトで確認したり、問題に関連するすべてのエンティティを調べて問題の根本原因を特定したりできます。

このセクションでは、TwinMaker Knowledge Graph を使用して根本原因分析のユースケースを実装する方法について説明します。

アプリケーション開発者は、部屋や空調ユニットなどの物理的なものを表すエンティティを作成し、コンポーネントタイプからインスタンス化されたコンポーネントを追加します。コンポーネントには、物理的なものを説明する属性またはプロパティが含まれます。たとえば、プロパティは階数などの記述子でも、外部データストアに保存されている温度測定値などの時系列データストリームでもかまいません。リレーションシッププロパティは、このエンティティがコンポーネントのコンテキスト内で他のエンティティとどのように関連しているかをキャプチャします。コンポーネントには複数のリレーションシップが含まれていてもいなくても、各リレーションシップは 1 つまたは複数のエンティティに接続できます。リレーションシッププロパティを定義するには、リレーションシップが参照するエンティティ ID とともに、リレーションシップタイプを指定する必要があります。

エンティティ、コンポーネント、およびプロパティを作成するには、AWS IoT TwinMaker コンソールを使用するか、CreateEntity API を呼び出すことができます。建物のレイアウトと物理オブジェクト間の関係を記述するオンボーディングスクリプトまたはクラウド形成テンプレートを使用することもできます。下の図は、ユーザー定義のコンポーネントが割り当てられた部屋を表すエンティティを示しています。属性の関係を記述する JSON オブジェクトが図にオーバーレイされています。このユーザー定義コンポーネントでは、「feed」、「isLocationOf」、「isMonitoredBy」の 3 つのプロパティが関係を定義し、「RoomNumber」と「RoomFunction」という 2 つのプロパティが属性を定義します。

アプリケーション開発者が建物を表すコンポーネント、エンティティ、およびリレーションシップを作成したと仮定します。以下の図は、TwinMaker Knowledge Graph クエリエディタの建物表示と、HVAC ゾーンが建物にどのように役立つかを示しています。

下の画像は、東部 HVAC ゾーンの TwinMaker Knowledge Graph をより詳細に表示したものです。

また、アプリケーション開発者がシーンコンポーザーを使用して建物の関連する 3D モデルをアップロードして設定し、Amazon Managed Grafana を使用してエンドユーザーがダッシュボードを使用できることも前提とします。3D モデルをインポートして Amazon Managed Grafana で視覚化する手順については、ハイパーリンクの付いたこのブログを参照してください。

AWS IoT TwinMaker で作成された建物のデジタルツインを使用して、TwinMaker Knowledge Graph がビルマネージャーが環境条件の問題をトラブルシューティングするのにどのように役立つかについて詳しく見ていきましょう。ユースケースの最初の部分では、ビルマネージャーは東部 HVAC ゾーンの部屋に関連するすべてのセンサーデータを表示したいと考えています。ユーザーは GetPropertyValueHistory API を呼び出して、エンティティ ID とコンポーネント名を入力として含むセンサーデータを取得します。最初のステップは、ビルマネージャーが関心を持っているすべての関連エンティティを特定することです。

TwinMaker Knowledge Graph が登場する前は、ListEntities API から各エンティティにビジネスロジックを適用し、そのエンティティが東 HVAC ゾーンの部屋のセンサーであるかどうかを判断する必要がありました。ユーザーは複数ページにわたる結果を処理し、リレーションシップデータを解析し、再帰的な API 呼び出しを何度も実行してリレーションシップをトラバースする必要がありました。TwinMaker Knowledge Graphでは、ユーザーは以下に示すようなクエリを作成できます。このクエリは、East HVAC ループの部屋に関連するすべてのセンサーのエンティティ ID を返します。以下のクエリは、ExecuteQuery API または AWS コンソールのクエリエディタを使用して実行できます。

SELECT e3.entityId
FROM EntityGraph MATCH (e1)-[]->{1,5}(e2)-[:isMonitoredBy]->(e3)
WHERE e1.entityName = 'AHU_East' AND e2.entityName LIKE 'Room%'
AND e3.entityName LIKE '%_Sensor'

上記のクエリでは、PartiQL 言語を使用してユーザーが可変ホップクエリとマルチホップクエリを指定できます。具体的には、MATCH (e1)-[]→ {1,5} (e2) は変数ホップクエリで、「Room」という文字列で始まるイーストエアハンドリングユニットから 1 ～ 5 ホップ離れたすべてのエンティティを識別します。マルチホップクエリ (e2)-[: IsMonitoredBy]→ (e3) を使用すると、文字列センサーで終わり、部屋と直接（シングルホップ）の関係を持つエンティティに特に関心があることを特定できます。:isMonitoredBy は、その特定の関係を持つエンティティのみを返すことを許可することで、結果をさらに制約していることに注意してください。このユースケースでは、東 HVAC ループのすべてのセンサーではなく、東 HVAC ループ内の部屋に接続されたすべてのセンサーが返されます。

次に、アプリケーションロジックはエンティティリスト (ルームセンサーなど) ID を繰り返し処理し、GetPropertyValue API を呼び出して最新のセンサー値を取得します。これらの結果は、上の図に示すように、単一時点のデータとしてダッシュボードに表示されます。今、ビルマネージャーは、すべての部屋の湿度と温度が設定値からわずかにずれていることに気付きました。

東 HVAC ゾーンの室内センサーを識別するという、他に類を見ない手間のかかる作業は、複雑なビジネスロジックではなく、TwinMaker Knowledge Graph によって処理されます。これにより、アプリケーション開発の複雑さが軽減され、アプリケーション開発者は機能の改善に集中できます。たとえば、建物の管理者は、給気温度の時系列データとエコノマイザの位置を比較することで、故障したエコノマイザを根本原因として特定できました。

このユースケースでは、ビルマネージャーは、エコノマイザが故障しているHVACエアハンドリングユニットの数が多いかどうかを判断するために、管理している他の建物を積極的に調査することにしました。他の建物でも同じ手順でデジタルツインを使用することになります。同様のクエリを使用してエンティティ ID を取得し、次に GetPropertyValueHistory API を使用してさまざまなデータを取得します。次に、給気とエコノマイザの位置のグラフを作成して確認します。

結論

このブログでは、ビルマネージャーがテナントの快適性の問題をトラブルシューティングするのに役立つ TwinMaker Knowledge Graph の使用事例について概説しました。ビルマネージャーは、TwinMaker Knowledge Graph でキャプチャされた物理的関係に基づいて、建物内にあるさまざまなデータソースを表示し、関連する部屋やセンサーにドリルダウンすることができました。これにより、ビルマネージャーは HVAC システムのゾーン内の問題を特定できます。次に、建物のデジタルツインダッシュボードの 3D シーンを使用して、根本原因に関する仮説を立てます。AWS IoT TwinMaker でモデル化された物理的関係を深く掘り下げることで、ビルマネージャーは特定の HVAC ゾーン内のすべてのセンサーを特定します。これらのセンサーからの時系列データを比較することで、屋上エアハンドリングユニットのエコノマイザが誤動作していることを認識できます。その結果、ビルマネージャーは時間を節約でき、顧客により良い問題解決体験を提供できるようになります。TwinMaker Knowledge Graph を使用すると、ビルマネージャーは問題を迅速に根本的に解決でき、他の建物でも同様の問題を積極的に探すことができます。このビルマネージャーのトラブルシューティング体験は、TwinMaker Knowledge Graph、統合データクエリ、3D ビジュアライゼーションなど、AWS IoT TwinMaker のさまざまな機能によって実現しました。

Cognizant 1Facility ソリューションの詳細と TwinMaker Knowledge Graph がお客様の問題解決にどのように役立つかについては、AWS ソリューションポータルのソリューションをご覧ください。TwinMaker Knowledge Graph の詳細については、AWS IoT TwinMaker での PartiQL の使用に関するこのドキュメントを確認し、AWS IoT TwinMaker コンソールを使用して独自のワークスペースを構築してください。

著者

Kick White は、IoT アプリケーションにフォーカスする AWS のシニアパートナーソリューションアーキテクトです。AWS に入社する前は、世界的に多角的なメーカーでコネクテッドモバイル機器と産業機器の IoT プログラムを率いていました。Nick は産業機械向けのシステムや高度な制御の開発も行っており、製品ライフサイクル全体を通じて接続デバイスの価値を認識していました。Nick は 現実世界の可視性をビジネス上の意思決定プロセスに取り入れることで、効率性と洞察力を引き出すことができる IoT に情熱を注いでいます。
Jameson Bass は AWS のパートナーソリューションアーキテクトであり、北米の Cognizant 社の RCGTH および MLEU（総称して「P&R」）業界をサポートしています。複数の企業で IT コンサルタントとして働いた後、AWS に入社しました。クライアントと協力してクラウド移行を行ったり、カスタムデータや分析ソリューションを構築したりしていました。
Julie Zhao は、AWS IoT TwinMaker に取り組んでいる AWS インダストリアル IoT チームのシニアプロダクトマネージャーです。2021 年に AWS に入社し、インダストリアル IoT の製品をリードするスタートアップを 3 年間経験しています。スタートアップの前は、シスコとジュニパーのエンジニアリングと製品に関するネットワーク構築に 10 年以上携わっていました。彼女は産業用 IoT 分野での製品構築に情熱を注いでいます。
Stephen Plechy は、Cognizant のテクノロジー担当チーフアーキテクトであり、クライアントのエネルギー使用量を測定および制御するためのスケーラブルなクラウド対応アーキテクチャを構築する、コグニザントのスマートビルディングイニシアチブの展開に注力しています。彼は、コネクテッドビル向けのビルディングオートメーションシステムと IoT プログラムの専門家です。Stephen の強みの一つは、大規模な商業ビルや分散した小売店にスマートビルディングテクノロジーを導入することです。Stephen はビルディングオートメーションの分野で 20 年近くの経験があり、Cognizant には3年間在籍しています。

翻訳はソリューションアーキテクトの井上昌幸が担当しました。