 |
| 天井等、高所に取り付けた端末で商品に取り付けられたビーコンを監視 |
モデルの再定義
本モデルは、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個のビーコンでプロトタイプ（後述）によるテストを行うことにしました。
ビーコンの保守・管理
ビーコンの導入時や故障時には、その UUID、Major、Minor 等を設定・変更する必要があります。多くのビーコンベンダーは、ビーコンのクラウドサービスにアクセスさせ、購入したビーコン情報を登録・更新させた後、メーカー独自のビーコンアプリケーションをインストールしたiOS/Android端末をビーコンに近づけて、その端末からビーコンの情報（UUID、Major、Minor、Measued Power、出力等）を登録・更新させます。下図は Aplix社のビーコン管理クラウドサービスの画面で、この画面でビーコンの各種情報を更新します。【Aplix社のビーコン情報管理用クラウドサービスの画面】
 |
| AplixのサービスはビーコンのCSVデータを取込/書出できる為、多量のビーコンを管理し易い |
Aplix社のケースでは上記で登録した情報に iOS/Android 端末上の MyBeaconTool でアクセスし、同端末をビーコンに近接させた上でビーコン情報の更新を行うことができます。
【iPad 上の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 | |||
| 5ｍ | 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 | |||
| 9ｍ w/obst.*3 | 1/4 | OK | 39/21903 | NG-14 | ||
| 1/5 | OK | 39/21920 | OK-1 | |||
| Total | 10 | 8 | 3 | |||
*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
 |
| 上図の[監視]をチェックすると端末の監視対象となる |
ビーコンの存否の監視は、天井などに固定されたiPad（端末）で行います。端末が3回連続してビーコンの検知をしないとそのビーコンは存在しないものと認識して、［存否］フィールドに「×」を書き込みます。
注：
閾値を1にして、1度でも非検知が発生したら即刻レコードに「×」を入力することも可能ですが、人、台車、移動中の物品に電波を遮られることを想定し、3に設定しています。
【iPad のビーコン監視画面】
 |
| 監視端末 = 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回にします。
【プロトタイプのビーコン監視タブの下部に表示されるスキャン情報】
 |
| 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台、数千円程度
- 遠隔操作により本体の起動、再起動、その他の管理ができること
- 遠隔操作によりビーコン監視ソフトを起動、再起動、管理できること
- 遠隔一括管理 ― 上記2と3の起動、再起動などを遠隔から全端末に対して一斉に実行できること
- 高信頼性 ― 24時間/365日稼働すること
- 端末の死活（ハートビート）監視 ― 端末故障時にユーザに通知する機能
次回は iPad/FileMaker Go を使用しない端末ソルーションについて考えてみます。
（土屋）
参考サイト
http://business.aplix.co.jp/beacon/beacon_faq.html
IoT/M2M関連リンク
- iBeacon の適用モデルを考える １ ― 美術館等での展示物案内と倉庫内での商品自動検索
- iBeacon の適用モデルを考える ２ ― 定位置ビーコン監視モデル ― 各商品にビーコンを取り付け、存否を監視する
- iBeacon の適用モデルを考える ３ ― 定位置ビーコン監視モデル（2） ― 各商品にビーコンを取り付け、Raspberry Pi により存否を監視する
- Androidを使用した多数移動体位置監視モデル ― 人、トラック、自動車などに Android を取り付け、その所在地を常時監視するモデル
- FMクライアントからサーバ上のODBC/node.js経由でデータベースをCRUDする ― IoT/M2M 環境でCRUDを担当する tpcsql.js のFileMaker クライアントでの利用
