Gravioのセンサー関連情報。一番人気は、同時接続数！

Gravio事業部のタルミです。過去、ハードウェアがソフトウェアをバンドルして来た経験から、逆もまたできるだろう、ソフトがハードをバンドルするのもありじゃない？

要は、ユーザー様がワンストップ、シングルウィンドウで簡単・迅速に利用開始できればいいよね、という発想から生まれた弊社のGravioサービスですが、そのお手軽さから、様々なユーザー様にご利用されはじめています。

お客様の“やりたいこと”は無償で貸し出ししているセンサーの種類からなんとなくの動向は見えてきていますが、

意外なセンサーのニーズが高かったりもします。

業種とセンサーの関連とか、このあたりは“企業秘密”ですので、ご提供できない情報も多いのですが、

“省力化・作業量軽減”と“利便性”を狙っている利用用途が多いのかなぁ、という感じですね。

‍

 今回は、そのようなGravioユーザー様からのご質問の中でも比較的多いものとして、

センサーの“接続数”に焦点を絞って話を進めていきたいとおもいます。

センサー同時接続数、検証開始！

 今回も、Gravio（有償版）で無償貸出対象の“Aqaraセンサー”を利用していきます。

センサーデータ通信の周波数帯域は２.4GHz、Zigbeeを使ったセンサーです。

‍

ちなみに、こちらもよくいただく質問なのですが、

“センサーからレシーバーへの通信距離”については別ブログでご紹介していますので、そちらをご覧ください。

『エッジウェア“Gravio”で提供される無償貸出センサーの電波到達距離と複数センサー（10台）の同時接続を試してみた』

今回は、同時にどのくらいセンサーが接続できるか、

その際のマシン負荷はどうなるのか、を簡単な検証結果と共にまとめてみます。

今回の測定メニューはこちら。

１：センサー個数　12個（うち１個はソフトウェアセンサー）での接続可否とマシン負荷

２：センサー個数　17個（うち１個はソフトウェアセンサー）で１と同様の測定

なお、測定に利用したPCはこちらです。

MicrosoftSurface Studio
　- CPU：Intel Core i7 6820HQ CPU @2.70GHz,2.71GHz
　- メモリ：16GB

ちなみに、Zigbeeの規格上の同時接続数は65,536台ですが、

そこまでの検証はちょっと厳しいで今回はこちらでお許しください。

ただ動画サイトなどで、大量の製品を消費する系の動画ネタはときおり見かけますが、さすがにZigbeeのセンサーを65,536台つないでみた、という動画は作成してもニッチ過ぎてカウンターは回らないでしょうし、ご勘弁を（笑）

というわけで、エッジで管理するセンサー数として一般的と思われる個数で

一度測定し、更にセンサー数を増やしたときの挙動を見ていく、という形で進めていきます。

まずは１ダース、１２個を同時に接続

 会議室とオープンスペースすべての温度を取ってみよう、ということで、

弊社貸出品の温度センサーをそれぞれの部屋に９つ設置し、あとは人感センサーとボタンスイッチを一つずつ。Zigbeeを利用して接続する物理的なセンサーはこれで１１個です。

さらに、弊社オリジナルの機能ですが、PCに内蔵、もしくは接続可能なUSBカメラとGravioが持つ“ソフトウェアセンサー”機能を利用し、撮影した画像から人数推測を行なう“バーチャルセンサーデータ”が１つ。

‍

すべての物理センサーは１つのZigbee USBレシーバーに接続、

それにソフトウェアセンサーからのデータが加わり、

合計１２系統のセンサーにより吐出されるデータをPC１台で受けとる、という状況を作りました。

すべてエッジ型で実装されているので、一切クラウドは利用せず、エッジ側で全センサーデータを収集し、処理しています（もちろん、Gravioソフトウェアセンサー機能もローカルで稼働しています）。

‍

ちなみに、検証期間としては１２月上旬から年を越して約１ヶ月間。

また、GravioのソフトウェアセンサーはCPUリソースを利用して推論を実行しますので、その実行間隔によって負荷が変化しますので、今回は10秒に1回の推論としました。

１ダースのセンサー同時接続とCPU負荷の結果発表

 全センサー接続後、すべてのデータが問題なくGravioに収集されていることが確認できました。

気になるCPU利用率は、Gravio動作中の平均で22％。この数字はOSそのものに加え、常駐している様々なサービスも含めてトータルのCPU利用率です。余談ですが、Surface Studioは常駐しているサービスが比較的多く、更に別用途でDBなどを動作させていますので、そこそこCPUを利用している状態と言えるでしょう。

そこで、別マシンではありますが、常駐サービスの少ない、Gravioだけを動作させているマシン（Core i7-7500U/メモリ16GB）でセンサー１個、ソフトウェアセンサーを10秒間隔で動作させた場合の数値は以下のとおり、全体でのCPU利用率はGravio動作時で８〜９％、GravioそのもののCPUリソース消費量は２〜３％前後という状況です。

このマシンにおいては、OSや常駐サービスなどでおよそ５％ほどリソースを消費している、という感じです。このマシン上で、ソフトウェアセンサーが動作したとき（AIが動作したとき）に瞬間的に20％と跳ね上がりますが、これはCPU側負荷があまり高くないときは動作クロックを落としているため、その状態でAIが瞬間的に動くと数値的に大きく見える、という感じに見受けられたので、１秒単位でAIを連続的に動作させる（CPUクロックを落とさないように利用する）ことにしてみました。

その状態でマシン全体のCPU消費率は15〜16％となり、うちGravioは10％前後のCPUリソースを利用していました。PC本体側が５％ほどリソースを利用しているので、上記の数値と合致しますね。

当然ですが、Gravio上で動作させるアクションの数によってもリソース利用率は影響を受けます。

今回検証したマシンでは他に複数のアクションが走っている状態です。こちらを絞ったり、他のエッジマシンに分散することで、利用率をコントロールすることが可能です。

また、ソフトウェアセンサー機能はAI/MLの特性上、ある程度CPUリソースを消費します。こちらを利用される場合は、ある程度マシンスペックに余裕を持たせることをおすすめいたします。

‍

更に人感センサーを５個追加、合計17個を同時に接続

先程のSurface Studio環境（センサー12個環境）に、更に人感センサーを５個ほど加え、マシンの負荷がどう変わるか、また、同時接続が可能かどうか見てみます。

マシンスペックごとのGravioのリソース占有率、ソフトウェアセンサーの負荷、などがある程度見えましたので、今回は純粋に物理センサーそのものの接続数を増やした場合の挙動を見てみようと思います。時期的には１月の中旬、先の検証後に１週間ほど追加で検証を行いました。 

‍

１７個のセンサー同時接続でCPU負荷はどう変わるか？

結論から言いますと、５個センサーを追加したぐらいでは、CPU利用率はほとんど変化がありませんでした。12個接続時と同じく安定して動作しています。

サイジングの際のポイント

 別ブログでも記載しましたが、実は5-6年前のPCでもGravioは動作します。

Windows 10（1803以上）の64bitバージョンOSが入っていることが必須条件であり、更に旧機材に導入する場合はクリーンインストールを推奨しますが、マシンスペック的に、センサー数の大小で要求スペックが変わる、というものではなく、

“どのようなアクション”をエッジ側で実装するか、のほうが重要な要件となります。

ソフトウェアセンサー機能も“AI”という“アクション”を実際にCPUを利用して実現していますし、また、センサーデータをGravio側に内蔵のDBから書き出したり、Gravio側にHTTP/MQTT送出などのアクションを実装すると、当然CPUリソースやメモリリソースを消費していきます。

直近のGravio導入マシンの一例ですが、一時期良くWindows 10タブレット製品で利用されていたAtom x5-Z8350など、決して高いスペックではない現行CPUでも動作実績がございます。従い、Gravio用マシンのサイジングに関しては、OSのバージョンは必ず検討いただき、あとは実際の使いやすさや入手可用性、コスト、サポート品質などを加味して選定をしていただければと思います。

（おまけ）禁断の“センサー殻割り”に挑戦してみた！

温度センサーの秘密を暴く

HACCPの記事（『HACCP義務化に向けてカジュアルIoTを活用』）を書いているときにふと思ったのですが、そもそも、基板上に設置されている温度センサーの取得する温度って、基盤の熱の影響を受けないものだろうか？電気回路のそば、チップのそばにセンサーがあると、その影響受けるだろうなぁ、と思っていました。

‍

特に冷蔵庫などの庫内温度を測定するとなると、

基盤自体が影響受けるよね、、、そんな話を弊社の代表としていたら

一言“ばらしてみたら？”と（笑）　電子工作系が好きな人は必ずそこに行き着きますね。

私も嫌いなクチではないので、早速、殻割りしてみました。

‍

趣味ではありますが、真空管オーディオなどでもよくある話なのですが、回路、配線、部材の配置ってすごく設計者の意思が現れますし、美しいものは美しい、んですよね。

車のエンジンルーム内の配置、特にバッテリーの位置なども、私は同じ目線で見てしまいます。

で、手元にある“温度関連のセンサー”の基盤を比較してみました。

温度測定センサー周りの設計がこのように違いました。

弊社の認証済みセンサーは、基盤の影響を極力受けない形で設計してあります。このあたりは表に出てこない、実利用時に影響してくる部分なので、ご紹介させていただきました。

なお、殻割りしたセンサーは無事に元通りに復活し、弊社冷蔵庫内で温度を日々収集しています（笑）

まとめ

おかげさまで、お客様から、“100個、200個のセンサーデータを拾っていきたい”というニーズをお伺いすることが増えてきております。

Gravioの特長でもある、導入コストのインパクトを抑えることができる仕組みなどがすこしずつ認知されてきているのかな、と思うのと同時に、ある程度センサーの同時接続個数に関しては情報を増やしていきたい、という思いがあり、今回の簡易検証を行いました。

今後、更に数を増やした形で検証を行っていくとともに、引き続き“現場”における知見やご要望をお聞かせ願えれば、と思っております。

‍

解決したい問題に直面されている“現場”の皆さまが

IoTをカジュアルに利用していただけるよう、より簡単に、よりシンプルに

やりたいことを実現できるプラットフォームとしてGravioをぜひ試してみてはいかがでしょうか。