投稿日

LoRaWAN Conference session2 全文書き起こし(2)

みなさんこんにちは、ソラコムマーケティングの熊崎です。
LoRaWAN Conference 2017のsession2「LoRaゲートウェイとデバイス 〜デバイス開発と、無線連携〜 」講演書き起こしブログをお届けします。当日来られなかった方、ご都合の合わなかった皆様、LoRaWANゲートウェイ・デバイスに求められる開発手法やネットワーク構築についてご紹介します。
本セッションは、M2Bコミュニケーションズの渡辺様、ウフルの竹之下様、ファームノートの阿部様にご登壇いただきました。ぜひご覧ください。

  1. LoRaWAN Conference session2 全文書き起こし(1)
  2. LoRaWAN Conference session2 全文書き起こし(2) ← 本記事はこちらです。

最終的に欲しいデータを、別の角度から工夫して取得

大槻:これからは、IoTデバイスの勘所をお伺いします。一般的なIoTシステムは、センサー系、デバイス、ゲートウェイ内の処理をするノード、通信をするモジュール、受け手となるサーバー、クラウド、アプリケーションノードで構成されます。
IoT構築をする上で、ポイントが4つあると思います。一つ目は、そもそも何をやるのかと実際に必要なデータは何かです。二つ目は、そのデータの利用場所です。三つ目は、データの処理はデバイス、サーバー、クラウドのどこで行うのか。実装、開発のために処理をする箇所を決める必要があります。四つ目は、いつまで使うかという期間です。
一つ目の欲しいデータは何か。実際の現場でどのような引き合いがあるか、教えてください。

M2B・渡辺:水量系、土砂崩れ、見守り系、遺失物のトラッキング、ショッピングモールでの活用など様々なお問い合わせがきています。

大槻:ありがとうございます。今回のソリューションの例は、物品管理でしたが、他にどのような具体的な案件がございますか?

ウフル・竹之下:LoRaは1回11バイトの制限があるため、直接的にデータを取る、例えば写真を送ることはできません。そのため、最終的に欲しいデータを間接的に取ることを考える必要があります。例えば、粉状の土などを送るフィーダーという装置の詰まりを検出したい場合、カメラで監視する方法もありますが、我々はフィーダーが詰まったことを、モーターの電圧から取ろうと検討しています。過剰な負荷が掛かっているときは、使用電圧、使用電力量が上がるため、それを11バイトに収めてデータを送信しようしています。またオフィスの中では、会議室を使っているか否かを、焦電センサーのような直接的に人を感知する人感センサーで取るか、それとも単純に照度センサーで会議室の電気が点灯しているか否かで、人がいるかを判定しています。欲しいデータは何かということから、間接的にどうやったらそれが判定できるかを考えて、どんなデータを取るかを考える必要があります。LoRaは、こう言った工夫が必要になると思います。

uhuru_takenoshita

大槻:取得された全てのデータを、クラウドに送信するのではなく、ある程度、デバイス側や、エッジ側での処理が必要になるというところですね。

ウフル・竹之下:処理とその取り方の工夫が必要になると思います。

大槻:最後にファームノート様にお聞きしたいことは、これまではGPSのデータを取得されていると思いますが、今後の活用としてどのようなデータが必要になってきますか。

ファームノート・阿部:牛単体では、活動量と位置情報、体温、咀嚼数、餌の消費量などが、お客様のニーズにあると思います。酪農分野に目を広げると、草のフィーダーから餌の消費量や、在庫量、資材の乗っているパレットの位置です。LoRaのゲートウェイ1台で、農場全域をカバーできることは、結構夢があるねという話を、お客様からいただいてます。

大槻:農家の方がマニュアルでやっていることを何とか自動化できないか、ということですね。完実際の活動量は、どういったセンサーで取っていますか。

ファームノート・阿部:活動量は加速度センサーを使っています。多くのデータ量をエッジ側での処理をせず送信しています。サーバー側でアルゴリズムを結構日々改善し、加速度センサーはBluetoothを使っていますが、将来的に処理をエッジ側にし、LoRaやLPWAで対応できるとは考えています。

LoRaの最適な利用環境とは?

大槻:利用環境、実際にLPWA・IoTをやるにあたり、利用環境が重要になってきます。外だったら奥まった場所なのか、屋内は宅内なのかマンションなのか等、様々な条件が出てくると思います。M2B・渡辺さんにお聞きしますが、LoRaWANで飛距離は期待できる思いますが、水道やガスなど奥まった箇所で使うシーンの結果はすでに立証されてますか。

M2B・渡辺:東京・八王子でエイビットが既に水道メーターの実証実験をやっています。鉄の蓋を閉めた状態で、漏れ電波で1.1キロ届いたという実証実験のデータもあります。屋外では、メータリングは使えると思います。室内はクラスメソッド社の案件もありましたが、大きなデパートを一つのゲートウェイで全てカバーできたと結果があります。屋外と室内の二つのタイプのゲートウェイを出しているため、組み合わせて使っていただけます。

m2b_watanabe

大槻:用途に応じて屋内向けのゲートウェイを使い、今後は屋外用のゲートウェイも予定していますので、用途別に使い分けていただくことが可能になります。今回発表のあったウフル様のソリューションでは、LoRa自体の通信はもちろんのこと、LoRaがゲートウェイ的な動きをし、BLEと連携しています。これは屋内でLoRaが届きにくいような場合も電波が拾えるところも意図されていますか。

ウフル・竹之下:今回BLEを使ったのは、例えば部屋の中にLoRaのモジュールを1個置き、それがBLE受信機も兼ねていると、部屋の中に温湿度センサー、照度センサーでビーコンを受信できる機能を全部1個のLoRaのモジュールで併用できます。BLEはたった数メートルか長くても10メートルしか届かないので、その10メートルとLoRaが届く数十kmから1kmを併用はうまくいったと思います。もともとPoCで様々なセンサーを付けたかったことが理由ですが、意外に良い組み合わせでした。屋内では1階から8階まで、全部我々のオフィス4階に置いたゲートウェイで通信できました。屋内のビルの中はゲートウェイ1個で十分だと感じましたが、鉄の扉の奥にある所などは難しいです。
データ処理の実施はどこで行うべきか。
大槻:続いてデータの処理は誰が行うかですが、センサーにつながるマイコンはRaspberry PiやArduino、mbedなど様々な選択肢があります。用途に応じて対応させていくことになると思います。センサーで送信できるデータと、送信できないが欲しいデータがあると思いますが、実際にどんなものが必要になってくるのか教えてください。

ウフル・竹之下: ソラコムが販売を開始する、LoRaモジュールの基板はArduinoシールドという形式で提供されます。これを使うと、Arduinoのピン配置に合わせれば、ホストコントローラーと言われる他のマイコンやRaspberry Piや様々なデバイスと非常にコンパクトに繋げることができます。今回mbedを使った理由は、電池の持ちの問題です。Arduinoはディープスリープという必要のないときには眠るあるいは止めることができませんが、それが可能な柔軟なマイコンを使いたかったので、mbedを使っています。なるべく長く使いたいため、データを飛ばすときにメタデータとして、一緒に電池の残量を飛ばしています。そのため、交換タイミングがわかるようになります。

大槻:実際お問い合わせで一番多いのは電池の残量を知りたい点や、サーバーに上げた際のタイムスタンプ、電界強度です。どこまでいけばどういったデータが取れるかは、お客様からのお問合せとしては非常に多いです。LoRaに関してデバイス単体で送れるデータは、非常に少ないので、ゲートウェイ側等での処理が必要になってくると考えます。

ウフル・竹之下:一つ諦めたデータがあります。実はLoRaの通信モジュールから送るときに時刻情報を付与せずに送っています。LoRaの通信モジュールでは時刻情報を付与しなくても、LoRaWANで取ってきて、そのコマンドがBeamから出てくるときにサーバータイムが付与されます。そこの遅れが1秒程なので割り切ってやっています。制約を回避するというか、時刻を諦めて、その分、他のデータを付与しています。

IoTデバイスの寿命は何年にするべきか。

大槻:最後に利用期間についてお伺いします。デバイス開発の際、期間がよく課題になると思いますが、実際にお客様からのご要望としてはどのくらいかをお伺いさせてください。

M2B・渡辺:案件によっては、10年と言われることがあります。10年持つものも電池の点では太陽電池を使い作ることはできますが、通信モジュールの寿命を考え大体5年ぐらいと申し上げています。通信頻度を上げるとバッテリーを使うので、送信頻度は一番ノウハウが必要な部分です。実証実験の場合はディープスリープモードの活用で、電池の持ちを長くすることもできるので、通信間隔も非常に重要だと思います。

ウフル・竹之下:デバイス側の考え方では、使い方によって寿命を延ばす、何年も動かすことはできますが、我々は元々クラウドサービスを提供している会社なので、実は10年提供するサービスは非常に難しいです。10年後も同じようなサービスを提供できるかどうかは、厳しいと思います。最近Amazonさんが出したAmazon Dash Buttonは、電池が1年ぐらいで切れます。電池が切れ、ものを交換してもらうのか、あるいはそういうタイミングで、サービスを終了させてくださいというタイミングをわざと作ったほうがいいと思います。特にコンシューマー向けのサービスは、あえて電池が切れる設計にするのも一つの考え方です。

ファームノート・阿部:1回牛に取り付けた後に、外すことはかなり負担になります。1回牛を集めて捕まえて、牛に取り付けているので牛にとっても負担です。なるべく回数は減らしたいので、お客様からは牛を飼っている間、実際に牛の商品価値がある7年~長くて10年なので、平均4~5年持つ電池はマストだと社内で話しています。

farmnote_abe

大槻:ありがとうございます。特に生き物だと、交換の負担は考える必要がありますね。

最後に、本日発表したLoRaWANのデバイスの組み合わせは、本日お話したセンサーデータの連携、データ取得、送信間隔を制御し消費電力を抑える部分、LoRaWAN自体の長距離伝送部分は、達成できているかと思います。ゲートウェイ側の処理は、タイムスタンプや、メタデータ部分、もちろん屋内外の筐体としての対応も進んでいます。サーバー、クラウド連携部分は、もともと弊社の特出している部分です。つまり、実は既にもうある程度環境が整っているところで、本日デバイスとゲートウェイを発表させて頂きました。
少し細かい部分ですが、下り対応技術が入ることによって、今回再送制御ができるようになっています。基地局からの下りの通信が対応できることにより、ACKを待つか・待たないという選択ができます。ACKがこなければデバイスは再送する、再送制御をすることで、通信の信頼性を高めます。

session2

実際の検証環境は、所有モデルと共有サービスモデルという位置付けがございます。PoCを実施する際、所有モデルをご利用いただいてももちろん結構ですし、共有サービスモデルのオープンな基地局を使い、検証が始めることも可能です。導入が容易なのは、後者です。今後徐々にLoRa Spaceという名前で基地局のスポットという所は増やしていきます。本日、お話にあったデバイス開発の勘所のポイントをなるべく押さえて、まずはIoTをやってみる。取りたいデータを簡単に取得できるよう、実装をご準備しています。よろしければ、SORACOM LoRaをお試しいただければと考えています。