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

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-14

FMクライアントからサーバ上のODBC/node.js経由でデータベースをCRUDする

 FileMaker(以下、FM)から FileMaker Server (以下、FMS)上のデータベースに接続し、SQLクエリでデータを CRUD する場合に考えられる方法は、通常は以下の2つです。

  1. FM クライアント機に ODBC を入れて、SQL を実行スクリプトステップを使用する
  2. FM クライアント機に ODBC は入れ、ODBCはサーバにのみ入れ、サーバサイドスクリプトで SQL を実行スクリプトステップを使用する

 1. のデメリットは、全てクライアントにODBCを入れる必要があり、保守が面倒なこと、
 2. のデメリットは、サーバサイドスクリプト内はデバッガが使用できず、またクライアントで実行する場合と動作が異なることがあること、です。
また、「\"」のエスケープが面倒で醜いというのは両者に共通した欠点と思います。

 さて、上記の2つの方法のデメリットを回避する方法として、サーバに ODBC/node.js と当方で開発した tpcsql.js を置き、FM クライアントから FMS に対して SQL を発行して CRUD する方法をご紹介します。

 以下で詳述のデータベースサーバ側でクエリ文を待ち受けする Node.js スクリプト tpcsql.js は、以下のページより無償ダウンロードいただけます。

tpcsql.js を使った CRUD テスト方法

以下、環境構築の方法を記します。

注:
  • cURLを使用するため、FileMakerクライアント は Ver.16 以降が必須となります。
  • FMSは Ver16 でのみ検証を行っています。  
  1. FMS 16 の Admin Console で ODBC/JDBC を有効にします。

  2. FM 付属の FileMaker ODBC ドライバを、サーバにインストールします。
    クライアントへのODBCのインストールは不要です。
  3. FMS サーバ環境に Node.js をインストールします。
  4. 上記のサイトより、tpcsql.js をダウンロードし、サーバ 上の任意の場所に配置します。
  5. tpcsql.js に付属の Readme.txt に従って、Node.js 関連パッケージ群をインストールします。
  6. コマンドプロンプト画面から、node tpcsql.js と入力し、Enter キーを押下します。
    以下のようなメッセージが画面に表示されたら、クエリ待ち受け状態となります。

    ここでは、Web サーバのデフォルトポート 80 で待ち受けしますが、すでに他の Web サーバが稼働中の場合は、tpcsql.js に記載されているポート番号を変更(例: 80→8080)し、再起動してください。
  7. 付属のサンプルファイル「TpcQueryTester10.fmp12」 をFMSに配置し、公開します。
    FMクライアントからアクセスできるように、必要に応じて、ファイヤウォールの設定を変更します。
  8. FMクライアントを起動し、上記7で公開したTpcQueryTester10.fmp12 を開きます。
    ログイン情報は tpcsql.js に付属のドキュメントを参照してください。
  9.  [URI]フィールドの hostname の部分を FMS16 のホスト名、または IP アドレスに変更し、“Go”ボタンを押してみてください。

    上記で、[odbcDriver]、[host]、[uid]、[pwd]、[database]フィールドは、FMS16 側から見た場合の設定をあらかじめ入力してありますので、そのまま “Go”で実行できます。
  10. 以下のようにクエリ結果が [result]フィールドに戻ってきたら成功です。
  11.  Data テーブルには 1000 件分のテストデータがあらかじめ登録されています。
    クエリ内容を変更することによって、CRUD 操作をお試しいただけます。
 本稿では データベースは FileMaker Server を使用していますが、MySQL や SQL Server など、ODBC対応であれば他のデータベースでもここに記載した方法は使用できると思います。

tpcsql.jsの他のプラットフォームでの利用

 当初、tpcsql.js は Raspberry Pi 等で iBeaconの情報を収集・加工し、リモートのデータベースをSQLで簡単にCRUDするという M2M な利用を意図して企画したのですが、「FMクライアントから使えたら便利かも?」と思い、公開することにしました。
 もともと、FMのサーバサイドで「SQLを実行」がサポートされているので、「?」な方もいらっしゃるかと思いますが、「役にたったよ」という方が現れたらウレシイです。
 尚、tpcsql.js のラズパイでの利用は、稿を改めてご紹介できればと思います。


(亀澤)

IoT/M2M関連リンク

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をアプリケーションサーバとして使用すると、いろんなことが簡単にできる可能性が広がると思います。


以上


(土屋)



関連リンク