Nature Engineering Blog祭 も１０日目、今日はファームウェアエンジニアの村田がお届けします。 今回のネタは『スマートメータのWi-SUN Bルート通信が安定しない原因の調査』です。 これは絶望的にニーズが無さそうな自覚がありますが、Nature Engineering Blog祭はNatureの技術に関することならなんでもいいよ！ということなので、このチャンスを活かして前から気になっていたことを仕事として堂々と調べてみましょう。
エネルギーマネジメント機器： Remo E / Remo E lite
Natureでは家庭でのエネルギーマネジメントを実現するデバイスとして、Remo E / Remo E liteを販売しています。スマホアプリで電気の使用量や太陽光発電・蓄電などの電力状況をリアルタイムで把握したり、過去のデータをグラフで確認することができます。
電気の使用量は、Remo E / Remo E liteがスマートメータ*1と無線で通信して情報を入手し、サーバを経由してアプリ画面に表示しています。リアルタイムにいつでも見ることができ、また過去に溯ってグラフで表示することができます。これらの機能を当たり前に使ってもらうために、ファームウェアはデバイス自身やスマートメータとの通信を安定動作させ続ける役割を担っています。 スマートメータとの通信にはWi-SUN ECHONET Profile for Route Bという通信規格を使っています。
特徴としては通信可能距離が500m程度と長く、回折性が高いため障害物に強く、低消費電力ということです。ほとんどの場合スマートメータは屋外に設置されているため、屋内に設置したデバイスから無線通信をするという使用シーンに適していそうです。
Wi-SUN の通信が思ったより安定しない？
開発当初、Wi-SUNは繋がりやすさを売りにしていることもあって通信エラーはそんなに出ないのだろうと思っていました。 実際に自宅のスマートメータ接続環境ではデバイスをスマートメータから一番遠いところに設置したり、金属で完全に覆ったりしても全然失敗しなかったので、そういうものなのだろうと考えていました。 しかし開発が進んでいくと、数％くらいの頻度で通信エラーが起こる環境もあることが分かってきました。
通信エラーは当然起こるものとして設計考慮しないといけないものではありますが、リアルタイムモニタ用途としてはできるだけ起こってほしく無い事象です。 例えば、通信エラーが起こったらリトライすればいいだけのことに感じると思いますが、Wi-SUNの場合スマートメータからの応答は非常に遅く20秒くらいしてから返ってくることもあるので、通信に失敗したと判断するのに結構待たないといけません。 またリトライを何度繰返しても応答を得られないようなときには、スマートメータとの接続認証が切れてしまっている可能性もあります。 こんなときには再認証するしかないのですが、一連の認証処理には数分かかってしまうのでその間はデータが取れない状態が続いてしまいます。 Remo E / Remo E liteはできるだけ可用性が上がるように通信頻度や待ち時間、通信リトライ回数、それでもうまく行かない場合の接続再認証などをバランスを取っていますが、万能ではありません。 安定してリアルタイムモニタリングをしてもらうためには、通信エラーが頻発するような環境は好ましくないのです。
当時はこの通信失敗率の環境差がどこから生まれているのかがわかりませんでした。都会は住宅が密集していて電波干渉がやばいのか、スマートメータが部屋から遠く離れた位置に設置されている集合住宅でなのか、はたまた大豪邸なのか、あるいはもっと全然別の要因があるのではないか、などと疑問に思いつつも深追いはできなかったのですが、違和感を感じていました。
調査スタート
ということで、Wi-SUN通信エラーの発生理由を追いかけてみましょう。 Natureではデバイスの動作ログ情報をAmazon s3に蓄積し、トラブルシュートに活用しています。 この中にはRemo E / Remo E liteのWi-SUN通信の成否、RSSI、通信遅延時間といったような情報も残しているため、まずはこれらのデータを見てみましょう。
データの抽出にはAmazon Athenaを使います。 Wi-SUN通信のログデータは１分毎にサーバに蓄積されているので、１デバイスあたり１日最大1440個のログがあることになります。 Athenaではスキャンするデータ量に基づいて課金されるので、軽い気持ちで大量のデータ処理をすると大きな請求が来てしまいます。 今回はデータの精度を求めているわけではないので、１日分のデータに絞って抽出してみましょう。 Athenaには分かりやすいGUIが用意されていて、SQL文を書いて実行すればすぐに結果が得られます。今回は簡単なSQL文を思い出しながら書くレベルでできてしまうので、ここは割愛です！
通信成功率、RSSI(平均・最小・最大)、通信応答時間(平均・最小・最大)の分布を折れ線グラフで表現してみました。まずは見てみましょう。
通信成功率いきなり違和感ありますね、ピークが２つできています。 RSSIはまぁこんなものですか、Wi-Fiだと-60dBくらいから不安定になってくると言いますが、Wi-SUNはどうなんでしょうね。 通信応答時間はピークが３つできています。
次に通信成功率とRSSI、通信成功率と通信応答時間、RSSIと通信応答時間それぞれの相関を調べるために分布図で表現してみました。
なんか期待した感じと全然違いますね？ もっとこう、RSSIが小さくなると通信成功率が下がっていくような分かりやすいのを期待したんですが、そうでは無いみたいです。 どれも相関があるとは言い難い結果となりました。
挙動の異なるいくつかのグループが混ざっているように見えるので、これをきれいに分離できたら要因を絞り込めそうです。 電波強度の問題ではないとなると、次に気になるのはスマートメータのメーカによる差ですね。 スマートメータからはメーカーの情報も取得できるので、Athena上でもうひと手間かけたら上記のデータをメーカー毎に分離できそうです。
メーカ別に切ってみる
まずはRemo E / Remo E liteユーザのスマートメータのメーカー比率を出してみました。
あくまでNatureユーザの中での分布ですが、A社が65%くらいの圧倒的多数、上位４社で全体の97.5%という寡占状態になっていました。
そしてメーカ毎に通信成功率をチェックすると見えてきました、最大多数のA社の通信成功率が他社より低めになっていることが。 グラフで書くとあからさまです。一番人気なのに！？という感じです。
A社のデバイスだけで通信成功率とRSSI、通信成功率と通信応答時間それぞれの相関を出してみましたが、やはり相関は見られません。 なぜA社との通信だけ失敗しやすいのか、ここが分かって解消できると全体の成功率がぐっと良くできるんですが、ちょっと今あるデータだけでは難しそうです。
A社以外も同様に通信成功率とRSSI、通信成功率と通信応答時間それぞれの相関を出してみましたが、こちらも影響して無さそうです。
ちなみに通信遅延時間はメーカ別で整理するとA社、C社が遅く、それ以外は比較的速いという結果になりました。 15秒以上経ってから返事が来るのはずいぶんのんびりした動きに感じ、意図的にやっているのかなという気がします。
まとめ
今回の調査でいくつかのことが分かりました。
- RSSIは-100 dB 以上であれば通信成功率への影響は無さそうなので、Wi-SUNは信号が弱くても繋がりやすいという特徴は確かに出てそう。
- 通信の遅延はスマートメータの内部動作に依存しているだけのようで、通信成功率には影響しない。
- あるメーカのスマートメータとの通信失敗率が高くなっている。困る。
- 他メーカのスマートメータでも、通信失敗率が極端に高くなっているデバイスが一部存在しており、何かまだ潜んでそう。
傾向を掴むことはできましたが、改善の糸口を見つけるまでには至りませんでした。 条件が似ているのに失敗率の差が出ているデバイスを絞り込んでより詳細に調べればもう少し追い込めるかもしれませんね。 Wi-SUN ECHONET Profile for Route Bのように、他社機器と接続するようなネットワークにおいてはすべての問題の原因を特定して解消することはなかなか難しいですが、より便利に、快適に使える状態を目指して今後も改善し続けていきたいと思います。
エンジニア積極採用中です
Natureでは一緒に開発してくれる仲間を募集しています。
カジュアル面談も歓迎なので、ぜひお申し込みください。
Natureのミッション、サービス、組織や文化、福利厚生についてご興味のある方は、ぜひCulture Deckをご覧ください。
*1:電力使用量を計測するための通信機能が搭載された電力メーター
