ラベル iBeacon の投稿を表示しています。 すべての投稿を表示
ラベル iBeacon の投稿を表示しています。 すべての投稿を表示

2018-08-09

iBeacon/Raspberry Pi による室内移動体位置監視モデル 2 ~ RSSI測定テスト ~

 前稿(18/4/10)では 室内移動体位置監視モデルに関する概要について記しました。本モデルは倉庫、施設、工場のような環境で、移動する多数のモノや人に iBeacon(以下、ビーコン)を取り付け、それらモノや人の位置を把握することを目的とします。

 図の端末(ピンク)はビーコン(青)からの信号を検知し、信号のRSSI(後述)から距離を算出します。端末⇔ビーコン間の距離が図の円です。各端末はビーコンとの距離しか算出できないため、複数の端末の距離データを使用してビーコンの位置を算出します。ビーコンが移動すると、最小の半径を持つ端末(TOP3)が替わるため、替わった端末(図ではPi12/15/16)が算出する距離データにより、その移動先の位置が算出されます。

 今回はビーコンの位置算出の要になるRSSIに関して小社で行ったテストについて記します。


RSSIと距離について

 RSSI(Received Signal Strength Indicator) はビーコンから発せられる信号の強度を示す数値で、ビーコンから離れるに従ってその強度は規則的に減衰します。ビーコン信号を受信する端末 ― ここでは Raspberry Pi(以下、RP、監視端末、端末と呼ぶことがあります)― はビーコン信号のRSSIを測定し、その減衰度により自身とビーコン間の距離を算出します。この信号強度は理論的には距離の二乗に反比例して減衰するのですが、実際には様々な電波干渉があるため、ビーコン⇔端末間の距離が長くなればなるほどRSSIのばらつきは大きくなり、その精度は劣化していきます。

例:ビーコン信号強度グラフ(Aplix 社のサイトより

 上図は、端末⇔ビーコン間の距離が1m を超えるとRSSIが急激に劣化し、ただ単にRSSIを測定してそれから距離を算出したのでは、実際の距離とはかけ離れた値となる可能性があることを示しています。
 本稿ではいくつかの環境で RSSIを測定します。さらに、その測定結果をもとに、RSSIの補正方法も考えてみます。


システム構成

実際に行ったテストについて記す前に、今回の開発・テストで使用したデバイスとシステム構成について説明します。

ビーコンと端末

 今回はテストでは、ビーコンには Aplix 社製 MyBeacon 汎用型ビーコン 、Gimbal社製 Series 10、Onix等を、ビーコンを監視する端末には Raspberry Pi Zero W/WH/3B/3B+ を使用しました。

 ビーコンは1つのメーカーに限定したほうがシステム開発も保守も簡単ですが、1メーカーへの依存はリスクを伴うため、複数メーカーのビーコン運用に対応したシステムを開発するため、テスト段階でも複数のメーカーのビーコンを用いました。

 端末は安価で定評も実績もある Raspberry Pi を使用しています。RPには多くの機種があり、信号受信アンテナの設置位置や無線チップも異なる(最新の3B+ではBCM2837B0、その他はBCM2837)ので、こちらも1つの機種限定したほうが簡単ですが、将来的な入手の容易性、拡張性、柔軟性を念頭に複数のシリーズを使用しています。

システム構成概要

 ビーコンから送信される信号はRaspberry Pi で受信・加工され、アプリケーションサーバを介して、データベースに書き込まれます。今回はデータベースに SQLite を使用しましたが、多数の端末を使用する場合はマルチユーザ利用に適した MySQL や PostgreSQL 等を使用する方が良いと思います。


プロトタイプについて

 今回テストで使用したプロトタイプは tpcbeaconsampler.js と tpclocation.js で node.js 下で動作するアプリケーションです。これらは相互に連携しながら各ビーコンの信号取得、端末⇔ビーコン間の距離算出、補正、データベース更新を担います。
モジュール名 用途
tpcbeaconsampler.js 端末にインストール。アプリケーションサーバからのリクエストに応じて、検知したビーコン信号を基にデータを作成し、アプリケーションサーバに送信する。
tpclocation.js ・アプリケーションサーバ上に配置。各端末に対してリクエストを送信。端末から受信したデータを必要に応じて再加工し、データベースを更新する。
・端末のリクエストに応じて、端末やビーコンに設定或いは蓄積された情報を送信する。

 

RSSI 測定テスト

ビーコンメーカーのAplix社は RSSI に影響する要因として、以下を上げています[リンク先]。なお、RSSIは信号強度を対数で示したものであり感覚的に把握し難いため、本稿では多くの場合、距離に変換しています。RSSI≒距離と考えて頂いて結構です。
  1. Beaconの送信出力、アンテナのゲイン、放射パターン
  2. 受信側スマートフォンの感度、アンテナの向き等
  3. スマートフォンOS内の処理(Bluetoothスタックの振る舞い他)
  4. 周囲環境(建材、人体等)による反射・吸収・回折

 このように RSSI値は様々の要因に影響を受けるため、端末が信号を受信しても、理論値と実際の計測値が大きく異なっている可能性があります。以下のテストは、RSSIがどの程度環境の影響を受けるのかをテストし、「考察」では補正方法についても簡単に記載しています。

※ビーコン補正について
 以下の文章中、「ビーコン補正」が「有」或いは「無」といった表記をしていますが、これはビーコン導入時に iPhone等によりビーコンから1m離れた地点で RSSI を測定し、その測定値の平均により補正を行ったか、行わなかったとを意味します。ビーコンの補正についてはApple社の Getting Started with iBeacon (PDF)の「Calibrating iBeacon」の項を参照してください。尚、RSSI の補正は本モデルの重大なテーマでもあります。

テスト1 1つのビーコンのRSSIを24時間測定


目的

固定した1つの端末と1つのビーコンを使用し、RSSIの精度、時間帯による変動をチェック

条件

  1. 1つのビーコンを1つの端末で24時間測定。
  2. 端末による1回のスキャン時間は5秒間。24時間で約1万7千のスキャンを実施。1回のスキャンで収集されるデータは平均34件、RSSIはスキャン毎に平均している。また、下図でRSSIは距離(m)に変換している。
  3. ビーコンと端末間の実際の距離:4.5m
  4. ビーコンと端末は固定してあり、移動しない。
  5. テスト中、ビーコンと端末の間、またはその周辺の人、モノの移動は最小限にする。
  6. ビーコン補正:有

結果

以下の2つ図は、データベースに記録されたデータをプロットしたもの。

【散布図1:時間経過と計測距離の変化】
RSSI はメートルに変換し縦軸に、横軸は計測時間。

横軸に距離、縦軸に発生件数を棒グラフ化。

平均(AVG):2.75m
標準偏差(SD) :0.88m
最大(MAX):9.96m
最小(MIN):0.93m









考察

  1. 端末⇔ビーコン間の実際の距離は4.5mだが、測定値では2.75m(平均値)で、かなりの乖離がある(実際の距離とは異なる)。また、最大値と最小値の差も大きい。
  2. 日中は距離の偏差が大きく、夜間に小さい。これは夜間は人間の発するWiFi等の電波による干渉が少ないためと推定される。また、日中は夜間に比し、値が上振れする。
  3. 以上のことより、距離の精度を上げるためには、時間に連動した応じた補正が必要。

テスト2 複数端末で複数ビーコンのRSSIを測定


目的

  1. 端末の個体差はどの程度あるのか
  2. BLEデバイスが異なると、RSSIに顕著な違いは発生するのか

条件

  1. 各端末によるビーコンスキャンは10秒間、1回のみ。
  2. 各端末が収集したデータは平均で50件弱。RSSI(表のaveRssi)は平均値。また、下表でRSSIを距離(Ave)に変換している。
  3. 端末(下図のPi1、Pi5-Pi8)から1m(Dist)の所にAplix(AP)10個とGimbal(GI)20個を配置。ビーコンは多数のため、端末との距離をできる限り1mに保つため格子状のプラスチックケース等に収納した。尚、Pi5 は 3B にBLEドングルを装着したもので、内臓BLEは無効化してある。
  4. ビーコンと端末は固定してあり、移動しない。
  5. テスト中、ビーコンと端末の間、またはその周辺の人、モノの移動は最小限にする。
  6. ビーコン補正:無

結果


Gimbal Aplix  
Dist RP Ave SD ave
Rssi
Sample num  Ave SD aveRssi Sample num 
1m Pi1 0.2m 0.15 -54.26 43.52 0.21m 0.09 -48.78 48.43
  Pi5* 0.86m 0.4 -67.86 56.23 1.21m 0.57 -63.97 59.05
  Pi6 0.18m 0.09 -54.25 43.86 0.27m 0.11 -51.05 44.92
  Pi7 0.25m 0.11 -57.18 42.38 0.36m 0.15 -53.16 46.52
  Pi8 0.16m 0.08 -52.97 44.9 0.21m 0.08 -48.85 46.47
  Summ. 0.33m 0.17 -57.3 46.18 0.45m 0.2 -53.2 49.08
凡例
* Dist:端末⇔ビーコン間の実際の距離。
* RP: Raspberry Pi 端末、Pi1/6/7/8は Zero W、Ri5 は 3BにBLEドングルを装着したもの。 
* Ave: RSSI(aveRssi)より算出した端末(RP)⇔ビーコン間の距離(単位:m)。
* SD:Aveの標準偏差
* aveRssi:全ビーコンがRSSIの平均
*Sample num:ビーコンから受信のデータ件数(平均)。各ビーコンから約46件づつ受信。
* Summ.:総平均

考察

  1. 同種の端末で同環境でテストしても、RSSIの値に差がでる。また、Pi5は BLEドングルを使用しているが、他端末の値との差が大きい。
  2. 上述のビーコン補正を行わないと、実際の距離は1mであっても計測されるRSSIに対応する距離は全くかけ離れた値になることがある。
  3. 以上、端末間でもRSSIの値に差異があるため、端末単位の補正が必要。

テスト3 ビーコンとメーカーによるRSSI(距離)の差異


目的

ビーコン間、メーカー間でどの程度RSSIに差があるのかを調査

条件

  1. ビーコンはAplixを20個、Gimbalを49個、1つの端末を使用。ビーコンを丸テーブルの円周上に配置。その上部に天井から吊るした端末と各ビーコン間の距離が1mになるようにする。
  2. 端末によるキャン時間60秒×5回を1セット。1セット終了後90度テーブルを回転させ、計4セット(60秒×5回×4セット)を実行。これは端末アンテナとビーコンの位置などにより、RSSIの値が異なることを想定し、値を丸めるために実施。
  3. 計20回のスキャンで端末が受信したデータ数は1ビーコン平均で約3600件。RSSIはスキャン毎に平均。下図ではRSSIを距離(m)に変換している。
  4. ビーコンと端末間の実際の距離:1m
  5. スキャン中、ビーコンと端末は固定してあり、移動しない。
  6. テスト中、ビーコンと端末の間、またはその周辺の人、モノの移動は最小限にする。
  7. ビーコン補正:無

結果

※上図で[0.2,0.25]は、距離が0.2m~0.25mと測定されたAplixビーコンが3台あったことを示す。
  Aplix Gimbal
AVG(平均距離)
0.4m
0.19m
SD(標準偏差)
0.11m
0.08m
MAX(最大距離)
0.6m
0.4m
MIN(最小距離)
0.2m
0.1m
Data Num(データ数)*
3618件
3606件

考察

  1. ビーコン個体についても計測値に差があり、最小値と最大値については3倍~4倍もの差がある。
  2. AplixとGimbalの平均値で約2倍の差がある。
  3. 以上のことから、個々のビーコンに対する補正と、ベンダー(ビーコンシステム)別の補正が必要。

 以上、時間帯、端末個体、端末種類(ビーコンシステム)、ビーコン個体、ビーコン種類(ベンダー)により、RSSIとそれに基づく距離が大きく異なることが判りました。
次回は大きく異なってしまう距離を補正できるか否かを小社で開発したプロトタイプを使用して検証し、本稿に加筆したいと思います。

(土屋)
Id:1147




2018-04-10

iBeacon/Raspberry Pi による室内移動体位置監視モデル1 ~概要~

 Raspberry Pi を監視端末し、iBeacon を取り付けた製品(以下、ビーコン)の存否確認を行う「定位置ビーコン監視モデル」については以前紹介しました。このモデルはビーコンが移動しないことを前提としていました。
 今回は Raspberry Pi 端末(以下、「端末」、「監視端末」と呼ぶことがあります)により、移動するビーコンをスキャンし、位置を把握する「室内移動体位置監視モデル」(英語では Indoor Location (Tracking) System 等と呼ばれています)について考えます。これにあたり、端末上でビーコンを監視し、 RSSI の取得、距離算出、ログ保存、データベース更新を行うアプリのプロトタイプも作成します。

 定位置ビーコン監視モデルに関する記事:

モデル定義

移動するビーコンの位置を把握するシステムモデルといっても、様々なものが考えられます。

例:
  1. 屋内ゲームでプレイヤーの持つスマホに自身(と他のプレイヤー)の位置を表示する(ゲーム機端末タイプ)
  2. 老人ホームや介護施設で入居者や患者の位置を管理者が把握する(高頻度スキャンタイプ)
  3. 工場の組立工程にある製品の位置を管理する(高頻度スキャンタイプ)
  4. 倉庫や保管場所にある製品の位置を把握する(低頻度スキャンタイプ)
  5. モノ・人の位置をリアルタイムに把握する(リアルタイムスキャンタイプ)
上記4のタイプは上記2、3のタイプに比べると、それほど頻繁にビーコンが移動することはなく、保管場所の変更など、稀に製品の移動が発生します。常時移動しないので、Raspberry端末からスキャンを実行して位置を特定する頻度は低くても良く、よってリアルタイム性を重視しないことを想定しています。
 これに対して、上記3、4のタイプは人や製品の位置をできるだけ迅速に把握する必要があるため、端末からのスキャンを頻繁に行うことを想定しています。
 5の「リアルタイムスキャンタイプ」は可能な限りリアルタイムな位置情報が必要とされるものです。
 移動体の位置監視システムはそのタイプにより仕様も運用方法に変わってきますが、本稿では、 高頻度及び 低頻度スキャンタイプについて考えます。

システム概要

 本モデルでは、監視端末をグリッド上に規則的に配置し、複数の端末が取得した同一ビーコンのRSSIにより端末とビーコン間の距離を算出し、その位置を推定することを目標とします。

監視端末のグリッド配置

ビーコンの位置を特定するにあたり、RSSI 等の情報を取得する Raspberry Pi 端末を碁盤の目状に10m間隔で配置します。すべての端末が常時あるいは一定間隔でビーコン信号をスキャンします。端末の座標はデータベースの端末テーブルに予め登録します。すべてのビーコン(製品)は赤枠内部に配置するものとします。

【図1:端末のグリッド】


位置情報更新ロジック

各Raspberry Pi監視端末は ビーコンスキャンを実行してRSSI(受信信号強度、Received Signal Strength Indication) を取得し、このRSSIに基づき端末とビーコン間の距離を算出します。その後、アプリケーションサーバを介してデータベースサーバ上にある各ビーコンの距離テーブルの距離データを更新します。距離テーブルには、ビーコン毎に3つ(または4つ)のレコードを保持しており、レコードには最もビーコンに近接する Raspberry端末3台のIDとビーコンまでの距離が記録されています。
 例えば、下図左上にビーコン(青)がありますが、このビーコンに最も近接する端末は Pi2、Pi5、Pi6であることから、このビーコンに従属する距離テーブルの3つのレコードには、これらの端末の ID と ビーコンと端末間の距離が記録されています。
 Pi1~Pi16までの Pi監視端末は常時スキャンを行い、Pi2、Pi5、Pi6以外の端末も図上のビーコンを検知しますが、ビーコンが移動しない限り距離が最小となる(最も近接する)端末は Pi2、Pi5、Pi6のままです。
 次にビーコンが矢印の位置に移動したとします。この時、距離が最短となる端末は、Pi12、Pi15、Pi16 となるため、3つのレコードは3つの端末IDとその距離情報により更新されます。

ビーコンの位置を算出 ― 三点測位

 上述のように、データベース上の距離テーブルには、端末IDと、端末⇔ビーコン間の距離が記録された3つのレコードがあり、端末テーブルには各端末の座標が保管されています。これらのレコードを元にビーコン位置をプロットすると、端末を中心にした3つの円が表示されます。3つの円が重なったエリアの中心にビーコンがあると推定されます。 この中心位置を求めるのが三点測位と呼ばれるもので、本システムモデルでは主としてこの手法を用いてビーコンの位置を特定することを最終目標とします。
Plotly により、3つの端末からビーコンまでの距離をプロット

考慮すべき課題 

以上、一見簡単にビーコンの位置が特定できそうですが、そこまで辿り着くのは大変です。 その理由は以下の通りです。

1. RSSI の精度

次稿で詳述しますが、RSSI は端末とビーコン間の距離が数十センチの場合は、そこそこの値が計測できますが、1mを超えると各種干渉を受けて急激に劣化し、あるタイミングでRSSIを単純に取得して距離を算出しても、実際の距離とは全く異なる値が出てきます。
 また、RSSIはその精度の低さに加え、端末付属のBLEデバイス、端末の設置場所、時間帯、ビーコン個体等々、さまざまな条件の影響を受けます。
RSSI は位置特定の基本となる最重要な要素ですので、RSSIの値を補正する手法が必要となります。本モデルでは、この手法についても考えます。

2.三点測位

RSSIによりビーコン間の距離が算出されると、前述のように三点測位によるビーコンの位置推定が可能となります。ただこの手法も3つの円が交わらないと機能しないため、その場合は単にエラーとするだけではなく、代替の手段を考えたいところです。

 次稿では実際に RSSI を測定し、その補正方法について考えます。


(亀)











 




2017-11-05

iBeacon の適用モデルを考える 3 ― 定位置ビーコン監視モデル(2)

 前稿では、iOS と FileMaker Go を使用して定位置にあるビーコンを監視する方法について記しました。この方法は簡単でとても導入しやすいのですが、ビーコンを監視する端末が多数となる場合、iPad や FileMaker の費用負担がのしかかってきます。また、数十台から百台を超える端末を管理するとしたら、iPad/iPhoneでは大変でしょう。 そこで小社では、FileMaker Go に依存せず、様々なプラットフォームで利用可能なビーコン情報収集サブシステム(以下、TpcBScan.js)を作りました。

多様なデバイスで動作する TpcBScan.js  

TpcBScan.jsは node.js、express.js、nobe.js等の node.jsファミリー群の環境下で稼働する ビーコン情報収集サブシステムで、Windows、Macintosh、iOS、Android、Linux 等をOSとするデバイスで動作します*1。デバイスはBLE対応である必要があり、BLEアダプタ未搭載の場合、BLEアダプタ(ドングル)が必要となります。
 その機能は FileMaker の RangeBeacons関数に準じますが、http リクエストに対して戻り値を返します。 戻り値にはRangeBeacons形式とJSON形式を指定できます。Macintosh/Windows の FileMaker から TpcBScan.js を利用する場合は、「URLから挿入」スクリプトステップを使用します。

*1 Windows (WebDirectを含む)、Maintosh、iPad、Linux (Raspbian) で動作することを確認しています


「FMEasy在庫 IWP/WD R1.5(開発版)」のユーザの皆様には、TpcBScan.js β版 をダウンロード頂けます。詳しくはこちらをご参照ください。(2017/11/8更新)

Raspberry Pi をビーコン監視端末にする

今回、ビーコン監視を行う端末には、安定性、廉価性、保守性に優れるRaspberry Pi(BLE と LANに対応する機種)を使用することにしましたが、BLE/LANであれば Raspberry 以外のデバイスでも構いません。

 システムを構築するにあたっては、各種処理をサーバを中心に行わせる方法と、 端末を中心に実行させる方法の2種類が想定されます。

左がWi-Fi/BLE付の Raspberry Pi Zero W(¥3,000位)、右が Wi-Fi/BLEアダプタを取り付けた Pi Zero(無印)


端末駆動型システム構成

2種類の方法の1つが「端末駆動型」(下図)で、Raspberry端末がビーコン管理に必要な情報(端末が担当するビーコンのUUID/Major/Minorのリストや 、テーブルに保存されている存否情報のリスト=ManagedBeaconsList)をアプリケーションサーバを経由しデータベースサーバから取得します。端末は担当するビーコンが発信する情報(ActiveBeaconsList)を TpcBScan.js を使用して取得します。端末は取得した ManagedBeaconsList と ActiveBeaconsList を比較し、差異があれば アプリケーションサーバに対してデータベース更新等のリクエストを行います。差異が全くない場合は、サーバに更新リクエストは行いません。端末が多くの処理を行うのに対し、アプリケーションサーバの処理はレコードの送信と更新に限られます。 この端末駆動型は端末数やビーコン数が多くサーバ負荷を軽減したい場合に有効なシステム構成と思われます。


図1

サーバ駆動型システム構成

もう一つの方法が下図のサーバ駆動型で、この場合、Rapberry 端末はサーバからのリクエストに応じて自身が担当するビーコンの情報(ActiveBeaconsList)をサーバに返すのみです。一方サーバは、上述の「監視端末駆動型」で端末が担った ActiveBeaconsList 作成処理以外の全てを行うことになります。サーバは各端末に順繰りにリクエストを送り、戻り値を処理していくため、端末が増えると「監視端末駆動型」に比べてサーバの負荷はグッと増えます。この構成は監視端末の数が少なく、サーバが過負荷にならない場合に有効なシステム構成と思われます。
図2

サーバ駆動型を FileMaker Server でやってみる

実は当初、「端末駆動型」システムでも「サーバ駆動型」システムでも、Raspberry(Linux) を使うのであれば、node.js/JavaScript や PHP 等によるWebプログラミングは必須だと思いこんでいたのですが、下図の構成であれば、FileMaker による開発のみで、「サーバ駆動型」を実現できることに気づきました。というのは FileMaker スクリプトには、「URLから挿入」と言うスクリプトステップがあり、このステップは FileMaker Server から実行できるからです。具体的には FileMaker Server から この「URLから挿入」を使用して、各 Raspberry 端末上の node.js に対して、ビーコン情報を返すように http リクエストを送ります。あとは「サーバ駆動型システム構成」で書いたように、FileMaker Server がすべての処理を行います。

図3

 ということで、小社では上図のシステム構成に基づき、多端末対応のFileMaker プロトタイプを作成し、4つの Raspberry と1つのWindows ― 計5台のビーコン監視端末を使用してテストを行いました。本来であれば500台程ビーコンを用意して、各端末に100台ずつビーコンを割り当ててテストしたいところですが、手持ちのビーコンが21台しかないため、各端末が同じ21台のビーコンを監視するように設定しています。

 下図が今回のテストで FileMaker で作成したプロトタイプの画面です。監視端末があるビーコンの情報を受信しない場合は当該ビーコンの[存否]フィールドに「×」が、受信した場合は「OK」が入力されます。


図4 FMPから“Multi-term. TpcBScan”を実行すると、後述のサーバサイドスクリプトが実行される

英語版の動画




 実際にFileMaker からサーバサイドのビーコン監視スクリプトを実行した時の FileMaker Server Console 画面が以下です。通常、[クライアント]にはコンピュータ名が表示されるのですが、サーバサイドスクリプトを実行している場合は、実行されているスクリプト名が表示されるます。 赤枠部がサーバから実行されているスクリプトで、このスクリプト([srv]subTpcB監視~)が5台の端末に対して ActiveBeaconsList (ビーコンから受信した情報)を FileMaker Server に送信するようにリクエストし、それを受信すると ManagedBeaconsList と比較して、必要に応じてデータベースの更新や、メール/SMSの送信等の必要な処理を行います。本「定位置監視ビーコンモデル」は継続してビーコンを監視し続けるモデルですので、赤枠部の各スクリプトは中止命令を受けるまで、常駐して処理を続けます。


図5

 さて、当初の予想ではこのシステム構成は サーバに大きな負荷がかかると思っていたのですが、実際にCPUのパフォーマンス(下図)を見てみると、予想ほどの負荷はかからないようです。
 FileMaker Server 16 は理論上は無制限(検証値的には500)の接続が可能ですので、理論上は無制限のビーコン監視端末を管理できます。

図6

SQL データベースの利用

前項では、FileMaker Server (FMS)は、ビーコン情報を取得し、ビーコンの存否を判断し、データベースを更新するというアプリケーションサーバとデータベースサーバの2つの機能を兼ねています。 一方、図3右下の点線部のように、ODBC対応のデータベースサーバ(以下、SQL DB)を利用する場合は、FMS をアプリケーションサーバとして使用することも可能と思われます。この場合、FMS は SQL DB に対する CRUD を担うことになりますが、CRUD には FileMaker の ESS と サーバサイドからの「SQL を実行」が使えます。以前、 FMS をSQL DB の帳票作成サーバとして使うという記事を書きましたが、FMSをアプリケーションサーバとして使用すると、いろんなことが簡単にできる可能性が広がると思います。


以上


(土屋)



関連リンク

2017-10-17

iBeacon の適用モデルを考える 2 ― 定位置ビーコン監視モデル

 前稿の末尾で iBeacon の「常時監視・単品管理モデル」に少し触れましたが、これは倉庫等の保管場所にある商品に iBeacon を取り付け、その存否(存在するのか、しないのか)を iPad 等の端末により常時監視するというものです(下図)。本稿ではこのモデルを掘り下げて考えてみます。

天井等、高所に取り付けた端末で商品に取り付けられたビーコンを監視

 

モデルの再定義

本モデルは、iBeacon が取り付けられた商品(以下、ビーコン)が多数存在し、システムでビーコンの存否情報を管理することを目的とします。各ビーコンを監視する端末は1つに定められており、その端末がビーコンの電波を受信しなくなった時点で商品は存在しないものとシステムは認識します。ビーコンは倉庫内を移動することは無い(例えば、上図のA区画から他の区画へ移動することは無い)ものと規定します。このモデルを「定位置ビーコン監視モデル」と呼びます。 これに対して、ビーコンが倉庫内を移動し、移動するビーコンを監視・管理するモデルを「移動ビーコン監視モデル」と呼びます。本稿では、「定位置ビーコン監視モデル」についてのみ扱います。


シナリオ

上図のように定位置にある多数のビーコンを監視するために、必要十分な数のiOS端末(以下、端末、iOS以外の端末に言及する場合はその旨を表記)を配置します。端末にはビーコンの存否(ビーコンの信号検知時には存在、非検知時には存在しないと認識)を監視するシステムをインストールしておきます。端末がビーコンの電波を検知しない場合、データベースのビーコンテーブルのレコードに記録(×で表示)し、ユーザにビーコンが消失したことを通知します。

ビーコンの選択

まず肝心要のビーコンを調達しなければなりません。本モデルでは個々の商品にビーコンを取り付けるので、多数のビーコンを使用することが想定されます。よって、ビーコンの信頼性、保守性、価格、プロダクトライフサイクルが重要になります。また、ビーコンの保守(UUID、Major、Minor、Measured  Power 、出力等の設定・更新)を行うには、多くの場合、ベンダ独自のクラウドサービスを利用することになるので、企業・組織によってはベンダーロックインを懸念し、面倒でも複数ベンダーのビーコン運用を要件とするかも知れません。

ビーコンメーカーとビーコン製品の選択

日本のビーコンベンダーでは、Aplix社アクセス社が有名なようです。Aplix社が料金やマニュアル等の情報を公開しているのに対し、アクセス社はユーザ登録を行わないと詳しい情報が得られないようです。今回は情報がオープンなところを良しとし、Aplix社の製品・MyBeacon® 汎用型 MB004Ac-DR1 (下写真の黒いビーコン)を調達しました。

 一社だけではなく異なるベンダーの製品もチェックすべきと考え、海外のメーカー1社からもビーコンを調達することにしました。海外では Estimote社が有名なので当初はここを第一候補としたのですが、2017年7月に問い合わせたところでは「現行製品には技適マークを取得したものはなく、8月に1製品で技適マークを取得する予定」とのことでした。この世界最大手のビーコンメーカーは米国等他の市場に手一杯で日本市場には手が回らない様子のため、今回はEstimote を見送ることにしました。

 次に候補に挙がったのが Onyx社で、ここは世界第4位のビーコンメーカーとどこかに書いてありました。同社の各製品は技適マークを取得しているところが高ポイントで、営業担当のビアンカさんの応答もとっても早かったです。ということでOnyx社から技適取得の製品 Beacon One (写真の白く小さな円形ビーコン)とEnterprise Beacon (白く大きな円形ビーコン)を3つ調達。2メーカー、3製品の計21個のビーコンでプロトタイプ(後述)によるテストを行うことにしました。

写真左の青いタグ型ビーコンは Gimbal社製 Gimbal Proximity Beacon Series 10
残念ながら今回のテストには間に合わず 

ビーコンの保守・管理

ビーコンの導入時や故障時には、その UUID、Major、Minor 等を設定・変更する必要があります。多くのビーコンベンダーは、ビーコンのクラウドサービスにアクセスさせ、購入したビーコン情報を登録・更新させた後、メーカー独自のビーコンアプリケーションをインストールしたiOS/Android端末をビーコンに近づけて、その端末からビーコンの情報(UUID、Major、Minor、Measued Power、出力等)を登録・更新させます。下図は Aplix社のビーコン管理クラウドサービスの画面で、この画面でビーコンの各種情報を更新します。

【Aplix社のビーコン情報管理用クラウドサービスの画面】
Aplix のビーコン CMS 画面
AplixのサービスはビーコンのCSVデータを取込/書出できる為、多量のビーコンを管理し易い


 Aplix社のケースでは上記で登録した情報に iOS/Android 端末上の MyBeaconTool でアクセスし、同端末をビーコンに近接させた上でビーコン情報の更新を行うことができます。



【iPad 上のAplix MyBeaconToolの画面】
Aplix MyBeaconTool
MyBeaconTool がクラウド上のデータを基にビーコンへの書き込みを行う。

ビーコンの性能・安定性

本モデルに限らずビーコンを使用したシステムでは、当然ながらビーコンが安定して動作することが重要です。下表は小社で開発したビーコン監視システムのプロトタイプ(以下、プロトタイプ、詳細は後述)を使用して、21個のビーコンを約60時間、監視テストした結果です。「Distance」はビーコンと端末の間の距離です。テスト中、ビーコンは移動していないので、本来であれば端末は常にすべてのビーコンを検知した状態でなければなりません。Aplixの10個のビーコンについては、60時間で端末が非検知と認識したのは1個体の1回のみで、高い安定性を示しましたが、Onyxは非検知が多く発生し、各個体で性能にバラつきがありました。
 尚、今回のテストにあたっては、各ビーコンの出力は初期値のまま使用しています。

Result of beacons heart-beats monitoring using iPad and FileMaker Go
Distance
Aplix MB004
Onyx One
Onyx Ent.*1
  M/M*2 Results M/M Results M/M Results
 0.1m 1/6 OK        
1m 0/2 OK        
2m 0/3 OK 39/20112 OK 1/7319 OK
0/4 OK 39/20168 OK    
5m 0/5 OK-1 39/20841 OK 1/7320 NG-288
1/1 OK 39/20862 NG-222    
9m 1/2 OK 39/21289 OK 1/7321 OK-4
1/3 OK 39/21351 OK    
9m  w/obst.*3 1/4 OK 39/21903 NG-14    
1/5 OK 39/21920 OK-1    
Total 10   8   3  
*1 Onyx Beacon Enterprise
*2 Major/Minor
*3 Beacons with obstacles placed nearby are 9 m away from device
*4 OK without number indicates  "Always detected by device"(signal never lost during test), Numbers beside OK/NG indicate the number of times beacons lost.


プロトタイプについて

今回、上表のテスト実施時に使用した FileMaker 16 によるプロトタイプの開発・テスト環境と仕様は以下の通りです。

■開発・運用環境
使用端末 iPad/iOS10.3.3
運用ソフト FileMaker Go 16
開発用ソフト FileMaker Pro Advanced 16
サーバソフト FileMaker Server 16
ベースソフト FMEasy在庫 IWP/WD R1.5」をベースにカスタマイズ
■仕様
UUID関連(下図) ・UUID/Major/Minor(テーブル、以下UMM) は階層構造とする
・UMMテーブルは商品テーブルとは分離する
監視(下図) ・RangeBeacon関数により指定されたUUID(複数指定可)を発信するビーコンを繰り返しスキャン
・設定した閾値を超えてビーコンが連続して非検知の場合、当該ビーコンのレコードに記録する(例えば、閾値を3とした場合、端末が3回連続してビーコンを検知しない場合、レコードに「×」と書き込む)


【UUID管理画面】0
FMEasy在庫の UUID 管理画面カスタマイズ例
上図の[監視]をチェックすると端末の監視対象となる

ビーコンの存否の監視は、天井などに固定されたiPad(端末)で行います。端末が3回連続してビーコンの検知をしないとそのビーコンは存在しないものと認識して、[存否]フィールドに「×」を書き込みます。
注:
閾値を1にして、1度でも非検知が発生したら即刻レコードに「×」を入力することも可能ですが、人、台車、移動中の物品に電波を遮られることを想定し、3に設定しています。

【iPad のビーコン監視画面】
FMEasy在庫のビーコン常時監視カスタマイズ例
監視端末 = iPad の画面。「×」は非検知ビーコン。複数のUUIDを持つビーコンを監視できる。

 

プロトタイプによる事前テストについて

 ビーコン導入のプロジェクト、特に多数のビーコンの導入を伴うようなプロジェクトでは、プロジェクトの初期段階でプロトタイプを用いたテストを実施すべきと思います。プロトタイプによりユーザの要求仕様の実現に目途をつけると共に、ビーコンの総数や、端末がビーコンの信号を安定して受信するためには端末をいくつ用意し、どのように配置するかという計画もこの段階で立てるようにします(じゃないと、概算費用も見積もれませんよね?)。

 上表の監視テストは、当方の事務所内で、なるべく障害物を置かない状態(上表の*3を除く)で、実施しています。ただ、表のテストとは別時間にほぼ同環境で実施したテストでは、端末から9mは離れたAplix社のビーコンが検知されないことがありました。Aplix社のサイトでは、端末がビーコン信号を受信できる距離について、「非常に大まかな目安」として「端末を手に持った状態で50~100m程度、鞄やポケットの中にある場合は30m前後」と述べる一方、「展示会などの人混みの多い場所では低い位置に設置したBeaconが人の列に阻まれ5mの地点でも受信できないケース」もあるとしています。また同サイトは受信の可否について以下が影響を与えるとしています。

    1.Beaconの送信出力、アンテナのゲイン、放射パターン
    2.受信側スマートフォンの感度、アンテナの向き等
    3.スマートフォンOS内の処理(Bluetoothスタックの振る舞い他)
    4.周囲環境(建材、人体等)による反射・吸収・回折

 倉庫などでは、多段のラックに商品を配置し、ビーコン信号がラックや他の商品に遮断されてしまうことも考えられます。
 プロトタイプによる事前テストでビーコンと端末の配置計画を作成します。実運用開始後もビーコンの非検知が多発するようであれば、非検知のエリアに端末を増設できるようにシステムを構築し、運用を工夫する(例:端末を増設した場合、その端末に担当させる商品群の Major は別の Major に変更する)ことも重要でしょう。

端末のスキャン速度

 本プロトタイプでは、端末が常時あるいは一定の間隔で対象とするビーコンをスキャンするのですが、その時に使用する FileMaker の関数が RangeBeacons という関数で、この関数にはスキャンするビーコンの UUID(Major/Minorも追加指定可)とタイムアウト(スキャンする時間)を引数として指定します。

 今回のテストでは21個のビーコンに3種類のUUIDを設定しました。RangeBeaconsを実行するには最低限 UUID を指定しなければならないため、21個のビーコンをスキャンするには異なる3つのUUIDを指定し、RangeBeaconsを3回実行する必要があります。また、タイムアウトをあまり短く設定するとスキャン漏れが発生するため、5(秒)に設定しています。つまり、21個のビーコンを1回スキャンするために3回RangeBeaconsを実行するので、それだけで15秒を要することになります。

 端末が担当する全ビーコンの1回あたりのスキャンをできるだけ短くするには、ビーコンの UUID または UUIDとMajorを合わせた値を1つに限定し、1回のビーコンスキャンで実行する RangeBeacons の回数を1回にします。

 【プロトタイプのビーコン監視タブの下部に表示されるスキャン情報】
iBeacon スキャン結果
RangeBeacons3回で15秒だがその他の処理もあるため、実際は22.2秒(平均)を要した。

監視端末と課題

本モデルにおいて、ビーコンと同様またはそれ以上に重要な要素は、監視端末です。ビーコンが安定していても、それを検知する端末が不安定ではシステムは機能しません。

 また、ビーコンを配置するエリアが広いと、端末数も普通は多くなります。野球のグラウンドのような一辺が100メートル、1万平米の倉庫にある商品にビーコンを取り付けるケースで、10m×10mの区画に分けて端末を配置するには100台の端末が、5m×5mの区画に分けて端末を配置するには400台の端末が必要になります。iPad が1台3.5万円、FileMaker Go ライセンスが1万円/年とすると端末1台に必要な初期導入費用は4.5万円、これだけで高額なシステムとなってしまいます。そもそもこのモデルで使用する端末はビーコンを監視し、その結果をデータベースに書き込むという単純なものなので、多数の端末を導入するケースでは、 iPad や FileMaker Go に代わるソルーションが求められます。

端末で考慮すべきこと

ここでは主に端末の価格について書きましたが、多数の端末を管理・運用する場合、小社が端末に求める要件は以下の通りです。
  1. 廉価性 ― 1台、数千円程度
  2. 遠隔操作により本体の起動、再起動、その他の管理ができること
  3. 遠隔操作によりビーコン監視ソフトを起動、再起動、管理できること
  4. 遠隔一括管理 ― 上記2と3の起動、再起動などを遠隔から全端末に対して一斉に実行できること
  5. 高信頼性 ― 24時間/365日稼働すること
  6. 端末の死活(ハートビート)監視 ― 端末故障時にユーザに通知する機能

次回は iPad/FileMaker Go を使用しない端末ソルーションについて考えてみます。


(土屋)

参考サイト
http://business.aplix.co.jp/beacon/beacon_faq.html


IoT/M2M関連リンク