Amazon Web Services ブログ
IoT@Loft #11 スマートビルディングにおけるIoT活用の取り組み
こんにちは、AWSソリューションアーキテクトの市川 です。6月17日に開催された IoT@Loft の第 11 回目であるこの回のテーマは、「スマートビルディングにおける IoT 活用の取り組み」でした。
スマートビルディングの領域では、ビルのセキュリティの確保や居住者への快適性の提供、またエネルギー利用のいっそうの効率化などの要求や、労働力の減少に伴うリモート管理や機械警備の重要性などの社会的なニーズのように、様々な領域で IoT を活用したソリューション開発の取り組みが行われています。
今回、様々な分野でビルディングのスマート化にご尽力されているエンジニアの方々にご登壇頂き、現場の課題とそれに応えるソリューション事例などをご紹介していただきました。
IoT@Loft とは ?
IoT 関連ビジネスで開発を担当するデベロッパーのためのイベントです。IoT の分野は、「総合格闘技」と呼ばれるほど、必要な技術分野が非常に多岐に渡ること、ビジネスモデルが複雑なケースが多く、全体を理解することは難しいと言われています。その結果、実証実験 (Proof of Concept : PoC) から商品への導入が進まないケースや、PoC でさえ十分に実現できていないケースも多々あります。
IoT@Loft は、そういった IoT 特有の課題と向き合い、情報共有・意見交換を行う場として、参加者の事業や製品開発を成功に近づけることができれば幸いです。この勉強会では、膨大な IoT 関連の情報の見通しを良くするために、各回ごとにテーマを定め、それに沿った形で登壇者に事例や技術のご紹介を頂きます。テーマは、インダストリー、ソリューション、テクノロジー、開発フェーズなどを軸に決めていきます。
セッションの紹介
3度目のオンライン開催でしたが、今回も多くの方に視聴していただきました。オフラインでは人によっては質問しづらいといったこともありますが、今回も多くの質問をいただいております。この記事では各セッションの概要について紹介した後、QAも紹介します。
LT1 – エネルギーマネジメントにおけるAWSを活用したIoTデータ取得ソリューション
登壇資料:エネルギーマネジメントにおけるAWSを活用したIoTデータ取得ソリューション
事例ブログ:ユーティリティにおけるAWS IoTを用いた分析・可視化（北海道ガス株式会社の事例）
こちらのセッションでは、北海道ガス株式会社より2名の方の登壇いただき、IoT初心者の非クラウドネイティブな社員による、PoC段階の検討に関して共有していただきました。
背景や課題として、建物はエネルギーシステム全体としての最適利用・省エネが求められるが、実際には個々のサービス・プロダクトは最適化されていても、それらをまとめて管理するのは、導入するお客様(ビルの管理等をされている方)となっていることでした。大規模な物件であれば、BEMS(Building Energy Management System) を導入しており、専門の人が計測・制御を行うことが多いが、中小規模の物件ではこれらの導入は難しいことがあります。また、北海道という土地柄、年間を通して寒暖の差が大きく、季節に合わせた機器の設定運用が必要というのが特徴としてあります。
今回は、このような中小規模のスタンドアロンなガス熱源設備に対するPoCを行ないました。目的としては、省エネ・設備最適運用支援を目的に、機器データを集めて蓄積・可視化することにフォーカスしています。
PoCを進める上で、1)どの様にデータを変換するか、2)PLCをどうゲートウェイに繋げるか、3)ゲートウェイ〜クラウドがよくわからない、といった課題がありましたが、一つ一つ解決しながら進めることでデータの収集から可視化までを進めることが出来ました。PoCの初期の段階ではSoracomさんのサービスを利用することで、データの蓄積・可視化を素早く行うことが出来たが、将来的に蓄積したデータを利用してBIツールとの連携や、分析を行うことを考えていたので、最終的にはAWS IoT のサービスを利用して、データレイクを構築し、可視化するところまで実現できました。これにより、熱源機器のデータを連携することで、省エネ支援を実現することが確認できました。PoCを進める上で、データ取得ソリューションは作り込まない事により、素早く構築することで現場の課題を早期に見つけることが出来たとのことです。
Q&A
Q. SORACOM HarvestやLagoonも使用されていたとのことですが、それらからAWSのサービス、IoT AnalyticsやQuickSightなどに移行、変更した理由について教えていただけますでしょうか。
SORACOMさんのサービスでもデータの蓄積は問題なく出来ますが、後々解析で利用したいという考えがありましたので、IoT Analyticsに移行しました。QuickSightは組み込みの異常検知の機能などあるためそれを使いたいと思い移行しています。
Q. 短期間での投資回収可能とのことでしたが、通信やクラウドを含めた全体のコスト感はどのくらいなのでしょうか？全体の構成の中で、特にどのあたりにコストがかかっているかを教えていただきたいです。
通信費用は安く済んでいます（数百円レベル）。一番コストがかかったのはPLCで、およそ10万円前後。クラウドは恐らく数千円ぐらいと思われます。ゲートウェイやソフトウェア等含め、トータルで数十万円レベルをイメージしています。どれぐらい省エネが出来るかによって、提供できるお客さまの範囲が変わるため、エネルギー使用量の少ないお客さんでも導入できるように、なるべくイニシャルコストを抑えるように心がけました。
Q. 実際に、セルラー以外でエネルギー設備から外部ネットワークを介してクラウドに接続するには障害はありますか
今回の事例では、客先設備内での機器設置だったため、客先のネットワーク設備を介したクラウド接続はセキュリティ面での課題整理が必要であり、難しいと判断しました。特に、SSHでのリモート保守を検討していたため、客先のネットワーク侵入はネックになると考え、セルラー回線を選択しました。
Q. PLCに付随するクラウドにデータを上げるサービスもあったと思いますが、今回の仕様にしたポイントはなんでしょうか？
PLCからAWSなどのパブリッククラウドに接続するサービスはいくつかありますが、上位PCが必要であることやコスト高になることが懸念されたため、今回のような簡易仕様としました。スマートファクトリー等の費用対効果が大きいような場面ではPLCとAWSをつなげる他社サービスの利活用は有効だと考えています。
Q. なぜSORACOMさんを選びましたか？
今後、安価な通信規格への変更や、多様なサービスへの接続も検討しています。こうした変更に対して守備範囲の広いSORACOMさんが有用と考えサービスを選びました。また閉域網通信が手軽に実現できるのも大きな選定基準の一つでした。
Q. 将来的には、クラウド側からの制御も視野にいれていらっしゃるのでしょうか？
視野に入れています。今回は紹介しませんでしたが、PLCへの読み込みだけではなく、書き込みもできることを確認しています。ただし、セキュリティ面や通信品質の課題もあるため、ベストプラクティスを検討中です。
Q. PoCを行うにあたり社内特に上司にはどのような説明をされたでしょうか？またPoCの結果を社内ではどのように評価されたでしょうか？
本プロジェクトを行う前に、IoTに関する取り組みを社内有志のメンバーで検討しており、少しずつ上司にアウトプットしていました。時間とコストをあまりかけずに、プロトタイプでの評価を説明していたため、スムーズにPoCに入ることができました。PoCの結果は、社内で比較的好意的に評価されており、自社でIoTシステムが構築できる自信がついたかと思います。しかし、多くの課題も見つかりましたので、現在サービス展開に向けて課題解決に取り組んでおります。
LT 2 – 警備ロボットの運用における AWS の活用紹介
こちらのセッションでは、SEQSENSE 株式会社様より、セキュリティーロボット(SQ-2)についての、アーキテクチャや現状の課題について発表して頂きました。
「SQ-2は、画像認識技術やセンサー技術など高度なテクノロジーを駆使することで生まれた自律移動型のセキュリティロボット。」と製品ページにあるように、建物のセキュリティー監視を行ってくれるロボットです。
セッションの中では、エレベータと連携して、複数のフロアを移動しながら不審者や異常の発見をおこなえることや、指示した場所に移動して確認させる動きも可能でデモ動画での紹介もありました。印象的な話として、AWS IoTを利用しているが、ロボットのアプリケーションの開発言語はGoで行われているということで、AWS公式のSDKが存在しないことから、自社で開発されてGitHubに公開しているという話や、Kinesis Video Streamsで保存された動画データをGo言語でパースするためのライブラリもOSSとしてGitHubに公開されていることでした。
課題としてあげていたこととしては、ロボットで動いているアプリケーションがGoで書かれていることもあり、Dockerのコンテナとしてアプリケーションを実行しているとのことでしたが、アプリケーションのアップデート(docker pull & restart)の仕組みを現在構築中とのことです。また、ステージング・本番環境への切り替えでの課題もあるとのことで、これらの課題を解決したあとの話も気になるお話でした。
Q&A
Q. なぜ、独自開発してまでGOを利用する必要があった背景を教えていただけませんでしょうか？
Dockerコンテナとの親和性、静的型付けによる型安全性、並列処理の書きやすさなどを理由に、弊社ではメインの開発言語をGoにしており、それに合わせた形になっています。実は昔sq-agentはNode.jsを使って開発をしていましたがメンテナンス性などを理由にGo版にリプレースしました。
Q. 三菱電機以外のエレベータでの連携も検討されていますか？
三菱電機さん以外のエレベータのビルへの導入がある場合は、行うことになります。実際に他社さんとのエレベータ連携の話も進んでいます。
Q. クラウドだけでなくロボット側の開発言語として主にGoを利用している理由はありますか？ロボット側ではCPUリソースなどの制約が厳しかったりするのでしょうか。
クラウド側のアプリケーションやロボットとクラウド間で連携を行うsq-agentはGoを利用していますが (理由に関してはQ1を参照)、ロボットの制御プログラムに関してはROSベースで開発を行っているのでPythonやC++がメインの開発言語になります。CPUや各種リソースに関しては潤沢にあるわけでは無いですが、一般的なIoTデバイスよりはある程度余裕があると思います。
Q. ロボットが動作中にオフラインになった場合に困ることがあれば教えてください。また、もしそれに対して考慮があれば教えて下さい。
オフライン時でも巡回業務自体は可能性ですが、オフラインの場合、クラウド側から状況確認が出来ない、操作ができない、エレベータに乗れないなどの問題があります。
SQ2はLTEのSIMカード経由でクラウドと常時通信を行っているのですが、オフラインにならないよう別通信会社のSIMカードを2枚使い通信を冗長化するなどの改善を検討しています。
Q. Go向けのAWS IoT Device SDKを開発されたとのこと、素晴らしいと思いました。一方で、AWSから提供されているSDKの言語では開発の要件とはマッチしなかったのでしょうか？
Q1でも書きましたが、弊社のクラウドチームではメインの開発言語をGoにしており、言語の統一性やメンテナンス性を重視した結果になります。
LT 3 – 長谷工LIM Cloudの紹介
こちらのセッションでは、株式会社 長谷工アネシス様より、BIM&LIM情報プラットフォーム構想や、LIM Cloud第1号物件についてのお話を発表して頂きました。
BIM&LIM情報プラットフォーム構想とは、設計施工の情報を一元化したものを「住まい情報であるBIM(Building Information Modeling)」と定義し、入居してから発生する様々な情報を活用していくことを「くらし情報であるLIM(Living Information Modeling)」として定義したものです。今までは、管理人や入居者から連絡を受け、点検し対応するといったアナログな対応でしたが、この構想によって、より安心・安全、快適な暮らしや住まいを提供することを目指しているとのことでした。このセッションでは、LIMの方にフォーカスした話について説明して頂きました。
この1号物件は2020年3月から入居を開始した、学生向けのITCマンションです。顔認証と差のサービスを連携することで、個人宛に荷物が届いていたらサイネージで通知したり、エレベータの停止階を自動で設定してくれたり、食堂利用の認証も行われるとのことです。気象センサーも設置されており、居住者向けのアプリで見ることが出来ます。建物内に設置された加速度センサーの情報は、地震の通知にも利用され、居住者への安否確認や、両親への安否確認結果を通知することも行われます。この様に利用者への利便性を向上される仕組みだけではなく、加速度センサーの情報は建物の劣化を調べるためのデータとして利用されるそうです。
QA
Q. 顔認証での自動ドア解除やエレベーターの操作ですがマスクをしていたり帽子をかぶっていた場合は開かないのでしょうか。住民の意見があれば教えてください
現状は、帽子やマスクで目元や鼻、口などが隠れた場合は認証されないため、外していただく様に案内しています。
マスクや帽子に起因する問い合わせは現状届いていないですが、対応の方向で検討はしています。
Q. 運用面からの質問となりますが、顔認証に利用する情報はどのようなプロセスで登録あるいは更新しているのでしょうか？また、その情報管理はＡＷＳのどのような仕組みでセキュアに保持しているのでしょうか？
居住者向けのアプリからS3に保存しています。セキュアな場所に保存しているため、外部からのアクセスは出来ないようになっています。
Q. これだけ素晴らしい施設になっていると、住居者からの有用なフィードバックはもちろん不具合の連絡などもあるのではと思いますが、住居者からのフィードバックの収集から施設への反映などやっていることがあれば教えて下さい。
アプリケーションから問い合わせ出来るようになっているのと、案内の用紙に問い合わせフォームというのが用意されているので、そこから出来るようになっています。
LT 4 – スマートビルディングを実現する AWS の IoT ソリューション
登壇資料:スマートビルディングを実現する AWS の IoT ソリューション
こちらのセッションでは、AWSのSAよりスマートビルディングにおけるIoTユースケースとAWSのサービスに付いて発表して頂きました。
スマートビルディングの主要ユースケースとして、以下のものが上げられていました。
- エネルギー最適化
- 保全最適化
- セキュリティー
- 居住者・動態分析
- 居住者利便性
スマートビルディングでは多種多様な機器ネットワークがそれぞれのプロトコルで構成されており、物理的な接続方法も異なっており、デバイスが直接クラウドにアクセスできないことが多いとのことです。そのような課題を解決するサービスとしてAWS IoT Greengrassがあり、このサービスを利用することで、直接クラウドに接続できない設備に対してクラウドのゲートウェイとして利用することが出来、様々なプロトコルの変換をゲートウェイ上で行ない、クラウドにデータを送信することが可能とのことでした。
アーキテクチャの例では外部のアプリケーションからリモート操作を行うものや、Amazon ElasticSearchやAmazon QuickSightを利用した可視化の紹介や、クラウド側のでリアルタイム映像分析防犯カメラのクラウド録画とライブ/オンデマンド再生の紹介がありました。
スマートビルディングのユーザー事例では、以下の事例について紹介がありました。
QA
Q. ElasticsearchのKibanaとQuickSightはどちらもダッシュボードがあると思いますが、どのように使い分けるのが良いでしょうか。
Kibanaのダッシュボードはよりリアルタイムな情報を表示するのに利用する際によく使われます。QuickSightはBIツールとしての位置づけですので、複数のデータソースから取得したデータを表示するのに利用されます。
Q. Greengrassはどのようなデバイスにインストールできるのでしょうか？
Linux向けのソフトウエアとなっており、こちらのサイトで紹介されているアーキテクチャで利用することが可能です。
次回 IoT@Loft
第12回目のIoT@Loftは、「B2C 向けのプロダクトの運用の考え方」という内容で開催いたします。
イベントの詳細や申込についてはこちらのサイトからご確認ください。
IoT@Loft ウェブサイト
https://aws.amazon.com/jp/start-ups/loft/tokyo/iot-loft/
IoT@Loft Connpass
https://iot-loft.connpass.com/
著書について
市川 純
AWS では IoT に関連するプロトタイピングを支援する、プロトタイピング ソリューション アーキテクトとして、お客様の IoT 関連案件を支援しています。