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

2018-04-10

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

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

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

モデル

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

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

ドローンフライト制御モデル

市販のドローンの多くはGPSを搭載しており、屋外では自身の位置を認識しますが、GPS信号の受信状態が悪い或いはできない屋内、ビル近辺、谷間等では、GPSによる位置計測ができないことがあります。 このような場合、ビーコンによりドローンの位置を把握し、フライトを制御する「ドローンフライト制御モデル」があります。 プログラムにより制御されたドローンで深夜に無人のビルや工場を巡回監視したり、撮影したりする用途が考えられます。

システム概要

 本モデルでは、監視端末をグリッド上に規則的に配置し、複数の端末が取得した同一ビーコンの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 を測定し、それから算出される距離と実際の距離を比較どの程度の誤差が発生するのかを見ます。さらに、小社で考案するRSSI・距離の3つの補正方法とその検証結果についてのも述べます。


(亀)


IPS関連のBlog記事



iBeaconよる位置測位調査(IPS)サービス 

土屋企画では iBeacon 利用した屋内位置測位調査(IPS)サービスを提供しています。 本サービスは貴社の社屋や施設にお伺いし、当方のIPS によりどの程度の精度でビーコン位置の計測をできるのか調査するものです。

詳細につきましては、こちらをご覧ください。

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関連リンク

2017-07-07

iBeacon の適用モデルを考える 1

 FileMaker 16 では「領域監視スクリプトステップを構成」というスクリプトステップが新たに加わりました。これにより、 iOS端末が予め指定する iBeacon の電波を受信すると、スクリプトをトリガすることができるようになりました。本稿では、FileMaker Go と iBeacon の利用モデルについて少し掘り下げたいと思います。

 尚、本稿を執筆するにあたって、 iBeacon と iOS端末を使用したテストを行っておりますが、実装を伴わない思考実験的な内容も含まれていることをお断りしておきます。

iBeacon 適用モデル

本稿では、よく紹介される展示施設でビーコン接近時に展示物等の案内や説明を端末に表示する「少数非近接ビーコンモデル」と、倉庫等で多数のビーコンが近接存在する環境で目的のビーコンを特定する必要がある「多数近接ビーコンモデル」について、続稿では倉庫等で物品一つ一つにビーコンを取り付け物品の存否等を管理する「単品管理モデル」について、計3つの適用モデルについて考えます。

少数非近接ビーコンモデル

 iBeacon の利用例記事で見かけるのは、美術館などの展示施設で iBeacon を配置し、iOS端末でビーコン信号を受信時に展示物の案内を表示する、というものです。
下図の例は、各展示エリアの入口(各円の中心部)に iBeacon を配置し、iOS端末を手にする訪問者が入口に接近するとビーコン電波を受信し、端末にはエリアの展示物の案内が表示される、というものです。

 FileMaker 16上の「領域監視スクリプトステップを構成」スクリプトステップは、最大20までの領域監視を設定できるので、図のような小規模なものであれば、アプリ開発者は同スクリプトステップの引数の UUID、Major、Minor を指定し、各エリアに配置された当該のビーコン信号を拾った時に当該エリアの案内を表示するようにアプリを開発するだけとなります。順路を逆戻りして一度見たエリアをまた見たいという訪問者は、そのエリアの入口付近に近づけば、再度スクリプトが実行されて案内が表示されます。

 それでは、20を超えるエリア(監視領域)がある場合はどうでしょう? 順路を設定できるケースではエリアを離れた時点でその領域監視を削除し、新たな領域監視を構成すればよいかもしれません。上図を例にとれば、邦画エリアを出て浮世絵エリアの監視領域に入った時点で邦画エリアの領域監視を削除し、21番目のエリアの領域監視を構成する、といった具合です。

多数近接ビーコンモデル

 次に倉庫の棚卸を考えてみます。メーカーA社は複数の倉庫を有し、まず調布倉庫で棚卸の効率化を行おうと考えています。現在は、複数の棚卸作業者が商品リストを片手に倉庫内を回り、棚にある商品を数えてその数をリストに書き込み、その作業が終了するとデスクに戻って棚卸数をPCに入力しています。

システム要件

 現在の棚卸方法に不満のあるA社の経営者は、新たに以下の要件を満たす iBeaconシステムを導入したいと考えています。
  1. 倉庫内にある各棚(下図の各区画(A~I)の「棚1」~「棚25」、計150台)の正面中央にiBeacon を設置。
  2. 複数の作業者が iOS端末を持ち、「各棚に接近して“近い商品検索”ボタンをタップすると最も接近した棚にある全商品が端末画面上に一覧表示される」(最近接棚商品表示要件)。
  3. 各作業者は上記3で表示された商品の棚卸数を入力。その棚の全商品の入力を終えたら次の棚へ移動し、同様の差作業を行う(以下、この繰り返し)。
    これにより、棚卸作業に要する時間を短縮する。
各棚の正面に iBeacon を設置

 上記の依頼を受けた開発者T君は、第一段階としてシステムのプロトタイプを作成してA社の要求仕様に合致するシステムが作成できるかテストすることにしました。まずデータベーステーブルの設計を考えます。iBeacon には UUID(32桁の16進数)、Major(0~65535)、Minor(0~65535)(UMM)を設定でき、iOS 端末は UMM を含むビーコン情報を受信し、さらに FileMaker Go 16 はこのビーコン情報を BeaconRange 関数で取得することがでます。 T君は iBeacon と各棚をデータベース上で1対1で結び付けるように、以下のようなテーブル/リレーション設計を行いました。

 このリレーションを使用して以下のようなレイアウトを作成し、倉庫/UUID、倉庫区画/Major、棚名/Minor を登録できるようにします。

各区画/各棚毎に領域監視の設定と解除のボタンも配置しているが、本モデルのテストでは不使用

 さらに商品テーブルには [UUID](倉庫)、[Major](区画)、[Minor](棚)フィールドを用意し、各棚とその棚に置かれる商品を関連付けます。こうしておけば、特定の棚(iBeacon)にある商品を UUID/Major/Minor により検索できるようになります。

 次にT君は“近い商品検索”ボタンの仕様について考えます。上述の「最近接棚商品表示要件」という条件を満たすために、調布倉庫の一区画を図にしてみました。ビーコンは各棚の正面に設置されています。

A区画図
iBeaconは各棚正面の真中(棚3と6では円の中心)に配置、円内がiBeacon信号の到達範囲

 iOS端末をPの地点へ持って行き“近い商品検索”ボタンをタップしたと想定すると、端末に最も近い棚1にある全商品を検索する必要があります。そこでT君はまず RangeBeacons 関数の引数に調布倉庫の UUID とA区画の Major を指定して、端末が受信するすべての棚ビーコンの情報を取得することにしました。この時、RangeBeacons 関数 は棚1ビーコンのほか、2、6、7、11もしかすると棚3のビーコン情報も拾ってきます。幸いなことに、RangeBeacons 関数はUUID、Major、Minor(UMM)の他に「精度」(ビーコンと iOS端末間の距離)も返してくれるので、この「精度」が最小の値をもつ ビーコンが最も近接した棚ということになります。こうしてT君は最近接の棚ビーコンを特定し、そのビーコンの UMM を持つ商品レコードを検索・表示するスクリプトを作成し、“近い商品検索”ボタンに割り振りました。これでプロトタイプが完成です。

 A区画でプロトタイプのテストを行う前に、A区画の棚1~棚25の全てに UUID、Major、Minor を設定した iBeacon を取り付け、A区画の棚にある全商品レコードの[UUID]、[Major]、[Minor] の各フィールドには当該iBeaconの UUID、Major、Minor を入力し、商品と棚(iBeacon)を関連付けしました。これでテスト準備完了、いよいよテストです。T君は iOS端末を上図のP地点へ持って行き、作成したプロトタイプを起動、“近い商品検索”ボタンをタップしました。この時、RangeBeacons 関数は下表の値を返していました。表で最小の[精度]を持つ棚は「棚1」であり、よってiOS端末P は「棚1」に最も近接しているので、T君の考えた「最近接商品表示ロジック」によるスクリプトが的確に動作し、「棚1」にある商品を画面上にすべて検索・表示しました。

棚番
UUID
Major
Minor
近さ
精度
rssi
棚1 BA80FEBE-6823-42ED-AA6A-XXXXXXXXXXXX 0 1 2 0.68 -62
棚6 BA80FEBE-6823-42ED-AA6A-XXXXXXXXXXXX 0 6 3 3.64 -74
棚2 BA80FEBE-6823-42ED-AA6A-XXXXXXXXXXXX 0 2 3 6.71 -83
棚7 BA80FEBE-6823-42ED-AA6A-XXXXXXXXXXXX 0 7 3 10.56 -83
棚11 BA80FEBE-6823-42ED-AA6A-XXXXXXXXXXXX 0 11 3 21.33 -88
上表は説明を補助するための表で、表の値とA区画図は一致しない可能性があります。

 ここでまではとても良くできたT君でしたが、一つ問題に気づきました。それは、RangeBeacons 関数の「精度」が不安定で常に値が変動する点です。特に数十cm以上離れると実際とは数倍異なる距離を返すことがあります。上記の調布工場のケースでは各ビーコン間の距離が結構はなれており、相対距離は正しい(最近接ビーコンの距離値が最小)になると想定されるので問題にならないかもしれませんが、ビーコン同士がより近接する環境では、上記の「最近接棚商品表示要件」を満たせない可能性があります。
 その場合は、電波を遠くに飛ばさない近接特化型ビーコンや、(上記システム要件を一部変更する必要がありますが)ボタンを押したときだけに電波を発信するタイプのビーコンの採用を検討する必要があるかもしれません。

参考:

常時監視・単品管理モデル

本モデルでは、各物品に iBeacon を取り付け、常時物品の所在を管理します。倉庫の天井などに固定した端末を通じて、物品に異動があるった場合は常にサーバ上のデータベースを更新し、異常があった場合の自動メール送信処理等も重要になります。単品管理が必要な物品は高額あるいは貴重なものとなるので、iBeacon の信頼性に加え、iBeacon の管理機能(多数あるビーコンの電池残量や製品寿命の管理や、故障時の交換処理の簡易性等)も重要になると思われますが、このモデルについては稿を改めたいと思います(次項)。




(土屋)


参考リンク

IoT/M2M関連リンク