2017-07-07

FileMaker 16 と iBeacon の適用モデルを考える

 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 の管理機能(多数あるビーコンの電池残量や製品寿命の管理や、故障時の交換処理の簡易性等)も重要になると思われますが、このモデルについては稿を改めたいと思います(次項)。




(土屋)


参考リンク
関連リンク

0 件のコメント: