ラベル 倉庫管理 の投稿を表示しています。 すべての投稿を表示
ラベル 倉庫管理 の投稿を表示しています。 すべての投稿を表示

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