2018-08-31

FileMaker Server の運用をオンプレミス、AWS、FileMaker Cloud で比較してみる

[本文へ移動]

コロナ蔓延により 優位性増すクラウド

本稿は2018年8月の記事で、クラウドとオンプレミスを項目別に評価(下表参照)しています。
 同表内のBCPの項ではクラウド(AWS/FMC)が優位にありますが、昨年の台風19号や今回のコロナの蔓延により、各企業・団体でのBCPの"重み"は急激に増しています。インフラ構築とその運用をすべてリモートで行えるAWS等のクラウドは、テレワーク/在宅勤務の観点からも優位です。

 土屋企画では、FileMakerシステムの移行を含むAWSインフラ及びテレワークシステムの構築を支援・実施致します。

参考リンク(土屋企画のWebサイト):
■AWSとテレワーク
■リモート開発とテレワーク
■Amazon connect と FileMaker WebDirect による CIT の無料試用サービスについて
(2020年5月1日加筆)

ローカル → EC2  vs  ローカル→Workspaces→EC2
 ~ FileMakerクライアントの実行速度を比べる ~

「FileMaker Cloud やAWS EC2 の FileMaker Server が遅い!」と感じていませんか? Amazon EC2 上の FileMaker Serverに、3つのクライアント(ローカルPC直接続、WorkSpace 1、WorkSpace 2)からアクセスし、データベースのソート速度を比較してみました。


(2020年5月14日加筆)

Amazon Connect と FileMaker WebDirect 19 による CTI


 Amazon Connect と FileMaker WebDirect 19 を連携させ、 CTI(Computer Telephony Integration) の主要機能の1つである「着信時顧客情報ポップアップ」を実現する事例をご紹介します。



(2020年6月15日加筆)

(以下、本文)
2017年7 月の FileMaker Cloud リリース以来、FileMaker Server のクラウド環境での運用も増えているようです。これにより企業では FileMaker Server 導入時に、オンプレミス(自社サーバ)、AWS EC2(Amazon社が提供するクラウドサービスで、ユーザは 自身で適切な Windows OS を選択て、FileMaker Server のインストールを行う)、FileMaker Cloud(FileMaker 社が Amazon マーケットプレースで提供する AWS EC2上で稼働する  FileMaker Server プラットフォーム)の 3 つのプラットフォームから選択することになります。

 ユーザはこれら3つのサービスでどれが自社に最適なのか悩むところですが、結論的なことを先に言ってしまうと、システム担当者がいない会社では FileMaker Cloud がお勧めです。FileMaker社が提供するチュートリアルに沿って設定を行えば、通常は数十分で FileMaker Server の準備が完了します。従来からある素の AWS EC2 に比べると、FileMaker Cloud は簡単です。

 オンプレミスかクラウドかはほとんどの場合、企業・組織がもつサーバポリシーによりほぼ自動的に決まってしまうかと思われます。データの秘匿性、セキュリティを重視する会社ではクラウド自身を禁止しているところもありますし、基幹システムはオンプレミスで、その他はクラウドに出すところ、IT部門の人員を削減するためサーバは全てクラウドにするところもあります。逆にサーバの仮想化をすすめ自社のサーバ室ですべてを運用することによりコストダウンを図る会社もあります(当社はこの形態に近いです)。

 本稿では、オンプレミス、AWS EC2、FileMaker Cloud の3つのプラットフォームを機能面と費用面から比較しています。機能については項目別に点数をつけていますが、企業・組織により各項目の重みは大きく異なるので、点数は参考値としてご覧ください。

 なお、3者とも FileMaker Server 17 の年間ライセンスを 25 使用することを前提としています。また、FileMaker Cloud はラインセンスのクラウドへの持ち込み(Bring Your Own License: BYOL)を前提としています。

 始めに機能・運用環境を比較してみます。FileMaker 社の公式ページ FileMaker ServerとFileMaker Cloudの比較 をベースに、さらに検討が必要と思われる項目を追加し、オンプレミス、AWS EC2、FileMaker Cloud 別に点数をつけてみました。

表1. オンプレミス、Amazos Web Service、FileMaker Cloud の機能・運用環境比較
No 比較項目 オンプレミス
(OP)
AWS EC2
(AWS)
FileMaker Cloud
(FMC)
説明
1 初期費用(ハード/ソフト) 1 5 5 表2参照
2  運用費用(ハード/ソフト)
4
3
2
表2及び表3参照
3  ハードウェア導入時の手間
2
4
4
OP:ハードウェア/UPS/バックアップ機器等の選定と購入が面倒
AWS:インスタンスタイプの選定のみ。OPに比べ簡単
FMC:インスタンスタイプの選定のみ。OPに比べ簡単
4  OS(選定/インストール/設定)
2
4
5
OP:自社で OS の選定、インストール、各種設定が必要
AWS:OSの選択は必要だが、インストールは不要
FMC: OS 選定もインストールも不要
5  FileMaker Server セットアップ
2
3
5
OP:自社ですべて行うため時間と労力がかかる
AWS:同上
FMC:20分程度(他に比べ簡単)
6  FileMakerライセンスの柔軟性
3
3
2
OP/AWS:自社で FMS ライセンスを用意する必要あり
FMC:AWS MarketPlace から BYOL、またはライセンス込みの FMC オプションを 選択可能。
AWS のユーザ登録とサーバ(EC2)、ストレージ(EBS)の指定が必要。
詳しくはFileMaker Cloud の購入方法を参照。
7  OS・ハードウェアの監視・管理
2
4
5
OP:社内担当者の負担大。
AWS:OS等ソフトウェアは社内担当者が管理、ハードウェアはAmazonにお任せ。
FMC:社内担当者の負担は最小。FMC 側でリアルタイム監視、OS更新通知、ソフトウェアパッチの自動通知
8  バックアップ
5
5
1
OP/AWS:サーバ管理者が計画、設定を行う必要があるが、バックアップスケジュールを自由に設定でき、単独ファイルのバックアップ、フルバックアップ等、柔軟な設計が可能。
FMC:FMC 側で自動メンテナンスを有効にすることによって自動バックアップ可能だが、サーバ環境の AWS スナップショットとなるため、バックアップスケジュールの柔軟性は低い。
FileMaker Cloud のバックアップの操作 を参照。
AWSスナップショットのバックアップはデフォルトで 20分ごとに実行される。一週間で計 504個のバックアップが保持され、古いものから順次自動削除される。よって、一週間より前のバックアップが必要な場合、他のバックアップ方法が必要となる。
バックアップのリストアは EBS ボリュームにスナップショットをアタッチする。ファイル単位の復旧は面倒(関連記事:FileMaker Cloud and Manual Backup Restore(英語))。
9  スケーラビリティ
2
4
4
OP:非仮想化環境の場合、ストレージ/メモリ/コア数の拡張には物理サーバ等のハードの入れ替えが伴うが、仮想マシンであれば拡張は容易で、費用は発生しない。
AWS/FMC:ストレジの拡張、サーバのアップグレードはオンラインで行えるが、拡張すれば運用コストもアップする。
10  最大アクセス数(FM社検証値)
5
5
3
OP/AWS:最大500 同時アクセス
FMC: 最大 100 同時アクセス
11  アップタイム(継続稼働)
3
4
4
OP:会社のポリシーと管理者の力量に依存。
AWS/FMC:99.99% のアップタイム(理論値と思われる。表外のコラム参照。
12  BCP(災害時復旧)
2
4
4
OP:災害被災時は焼失等により復旧不能となる可能性あり。同時被災の可能性が少ない遠隔地ストレージへのバックアップが推奨される。
AWS/FMC:OPに比べ影響を受ける可能性は少ないと思われるが、被災可能性は無いとは言えない。
13  ネットワーク
5
3
3
OP:LAN専用の場合、インターネット環境に影響されない。WANの場合は回線品質に依存する。
AWS/FMC:インターネット接続必須。実行速度はAWSのインスタンスタイプに加え、自社が使用する回線品質にも依存する。OPに比べ、WANの構築は容易。
14  サーバ証明書
3
3
3
OP/AWS:自前の証明書をインストールする必要あり
FMC:Comodoの試用版SSL証明書が付属(90日)
15  サーバ認証
4
4
3
OP/AWS:FileMaker ユーザアカウント認証、Active Directory/Open Directory および OAuth 2.0 アイデンティティプロバイダを使用した外部認証
FMC:FileMaker ユーザアカウント認証、 OAuth 2.0 アイデンティティプロバイダを使用した外部認証
16  サーバサイドスクリプト
5
5
2
OP/AWS:サーバ管理者が計画、スケジュール設定
FMC:スケジュール機能は限定的
17  ESS
5
5
2
OP/AWS:ESS使用可
FMC:ESSアダプタ以外は ESS 使用可
18 ODBC/JDBC
5
5
4
OP/AWS:ドライバのインストールが必要
FMC:ドライバのインストールが必要、専用ドライバの提供あり
19  プラグイン
5
5
3
OP/AWS:使用可能
FMC:一部対応していないものがある可能性あり
20  カスタムWeb with PHPおよびXML
5
5
-
OP/AWS:使用可能
FMC:使用不可
21  FileMaker Data API
3
3
3
OP/AWS:使用可能
FMC:使用不可
注:
本機能は1ライセンスあたり年間24GB のアウトバウンド転送量が付属するが、この転送量を超過するとライセンスを追加購入するが必要ある
土屋企画評価
73
86
67

 2019年8月14日、DNS の問題により、FileMaker Cloud for AWS にアクセスできない問題が発生しました。

 FileMaker Cloud の DNS障害について  [FileMaker Community]



 2019年8月23日、AWSの東京リージョンで大規模な障害が発生しました。



 同日17時現在、当方で利用している東京リージョンの AWS EC2 にはアクセスできましたが、AWSの Service Health Dashboard をみると、まだ完全復旧はしていないようです。9時~17時までの8時間、システムが停止している会社もあるかも知れません。

 上記のような障害は頻繁に発生するものではないと思いますが、クリティカルなシステムでは想定しておかないといけないですね。

 AWSかオンプレミスか、最先端のAmazon AWS vs 自社システム部門… 明日はどっちだ!

参考:
2018年からAWS東京リージョンでもリージョン間VPCが可能になっていて、リージョン間クラスタの構築が可能だそうです(参考記事)。今回の障害発生時、リージョン間クラスタは機能したのでしょうか。


 次に初期費用をシミュレーションしてみます。下表が、オンプレミス、AWS EC2、FileMaker Cloud 導入時に発生する諸費用となります。

 当然ですが、オンプレミスは自前のサーバが必要となります。サーバが無い、あるいは既存のサーバに空きが無い場合、サーバを購入しなければなりません。

 これに対し、AWS および FileMaker Cloud は、初期費用としてサーバ証明書と FileMaker 年間ライセンス費用のみとなるので、初期費用を抑えることができます

表2. サーバ仕様と初期費用比較
No. オンプレミス
(OP)
AWS EC2
(AWS
FileMaker
Cloud(FMC)
補足
1  サーバ証明書
(COMODO 企業認証タイプ SSL)
¥27,864 ¥27,864 ¥27,864 ・金額は消費税込み。
・FileMaker Cloud はComodo試用版SSL証明書が付属(90日)するが、90日以降の運用を想定して料金に追加
2  FileMaker Server
年間ライセンス費用
¥390,000 ¥390,000 ¥390,000  
3  サーバ配置場所
自社
AWS AWS  
4  リージョン
自社
東京 東京 「東京」のAWS正式呼称:Asia Pacific (Tokyo)。FileMaker Cloud の場合、アジアで選択できるリージョンは、東京とシドニーのみ
5  フルフィルメント・オプション
AIM AIM AIM:Amazon Machine Image (64bit アーキテクチャ)
6
 サーバタイプ
(インスタンス種別)
EC2(t2.large)
EC2(t2.large)
 
7
 HDD/EBS
(追加ストレージ)容量
1000GB
40GB
40GB
FileMaker Cloud は40GBがデフォルトで付属
8
 メモリ
8GB
8GB
8GB
 
9  コア数 2 2 2  
10
 CPU
Intel Xeon
Intel Xeon
Intel Xeon
 
11  クロック
3.3GHz
3.3GHz
3.3GHz
 
12  OS
Win Svr 2016
Win Svr 2016
CentOS Linux
Win Svr 2016:Windows Server 2016
13  サーバハードウェア初期費用
¥300,000
¥0
¥0
OPはUPS、バックアップ機器等のサブシステム費用を含まず
初期費用計 ¥717,864 ¥417,864 ¥417,864  
備考:

年間ライセンスと永続ライセンスはどちらがお得なのか

同一バージョンの FileMaker Server を 3 年以上使する場合、永続ライセンス(買い切り)を購入したほうがコスト安となります。
 とういのは、FileMaker Server を 25ユーザで運用する場合、年間ライセンスは 39万円、これを 3年間使用し続けるとすると年間ライセンスは 117万円となり、この費用は永続ライセンスの金額と同額となるからです。
 よって、3年以上を超えて長く運用すればするほど永続ライセンスがお得です。

 なお、永続ライセンス自体は FileMaker Cloud で使用できない点にご注意ください。
 
 最後に月々の運用コストを比較してみましょう。

表3. 運用コスト月額概算比較
No. セットアップ項目 オンプレミス
(OP)
AWS EC2
(AWS)
FileMaker Cloud(FMC) 補足
1  1日の稼働時間(H)
24
24
24
 
2  消費電力(W)
400
400
400
ラックマウントサーバ Dell R330 相当の消費電力
3
 30日分の消費電力(kW)
288
288
288
400W X 24H X 30日÷1000 として計算
4  電力単価*2
¥17.60
東京電力の料金(夏季)
AWS/FileMaker Cloud は電力請求なし
5  電気代
¥5,068.80
AWS/FileMaker Cloud は電力請求なし
6  AWS の時間単価
$0.13   EC2(t2.large)
7
 FileMaker Cloud の時間単価
$0.117 EC2(t2.large)
8  30日分の料金
$93.60 $84.240 24H × 30日 × 上記時間単価(割引適用無し)
9 9 AWSのストレージ料金(40GB)
$4.80 料金に含む FileMaker Cloud で割り当てられる EBS (40GB)
目安
10  アウトバウンド転送料金 (50GB) ¥0 $6.86 $6.86 保守用のデータ転送として 50GB を想定
11  AWS/FileMaker Cloud 料金合計
$105.26 $91.10  
12  米国ドル為替レート
(2018/08/29 時点)
¥111.15
¥111.15
 
運用費用月額計*1
¥5,069
¥11,700 ¥10,126 *OPは高負荷状態を想定、冷却空調費用含まず


FileMaker Cloud の申し込みの柔軟性について

FileMaker Cloud のライセンスは、 BYOL(既存のライセンスの持ち込み) とマーケットプレース(5/10/25/100ユーザライセンス)での購入に分類できます。
 請求に関しては hourly(時間請求) と annual(年間請求)という分類になります。

 一見、簡単なようにみえますが、以下のようなことを考慮する必要があります。
  1. FileMaker Server の永続ライセンスは使用できない。但し、永続ライセンスを年間ライセンスに変換すれば Cloudでの使用が可能。
    永続ライセンスを年間ライセンスに変換し、FileMaker Cloud に適用するまでの手順が公式動画で紹介されています。
  2. BYOL はリザーブド・インスタンス(インスタンスの年間契約)を選択できないため、hourly (時間請求)の一択になる。
  3. BYOL を使用しない場合、hourly(時間請求)または annual (年間請求)を選択できるが、ユーザ数の区切りが 5ユーザ、10 ユーザ、25 ユーザ、100 ユーザの 4 択になる。同時アクセスユーザ数が 30 など、中途半端になる場合はコスト高になる可能性がある。
  4. annual を選択すると途中解約やダウングレードができない。この件に関するサポートやアップグレードの要望がある場合は要問合せ(英語)
FileMaker Cloud 自身の操作では、 BYOL を AWS のリザーブド・インスタンスに適用できない件は、FileMaker 公式のオンラインコミュニティでも議論されています。
 参考:BYOL to a reserved instance on FileMaker Cloud (英語)

 スレッド内でも言及されていますが、あらかじめ AWS でリザーブド・インスタンスを購入しておいて、後で FileMaker Cloud の BYOL に結びつけるという裏技もあるようです。ただし公式対応ではないため、微妙です。
 参考:Using an AWS Reserved Instance with FileMaker Cloud (英語)

まとめ

すでに社内に仮想環境があるのであれば、仮想マシンを一つ作成するだけで FileMaker Server 環境を構築できますので、FileMaker Cloud の必要性は低いと思います。これはAWS 等のクラウドを運用中の企業でも同様です。

 社内にサーバ技術者がいない、いろいろ考えず手っ取り早く FileMaker を試用したいといった場合には、 FileMaker Cloud が威力を発揮すると思います。ただ、FileMaker AWS への登録、キーペアの作成、FileMaker Cloud 申し込み、FileMaker Cloud へのキーペア紐づけ等の設定は最低限必要になるのでご留意ください。


■ FileMaker Cloud 関連情報(随時更新)
FileMaker Cloud のチュートリアル(18/09/04追記)

FileMaker Cloud スターティングガイド(18/09/04追記)

FileMaker Cloud Support ページ [英語](18/09/03追記)
FileMaker Cloud に関するサポート情報がコンパクトに表形式でまとめられています。



参考リンク:
*本稿執筆にあたり、以下を参考にしています。
FileMaker ServerとFileMaker Cloudの比較 [公式サイト]
FileMaker Cloud 技術仕様 [公式サイト]
ファイルメーカー、「FileMaker Cloud」の日本リリースを発表 [公式サイト]
料金単価表‐電力(従来からの料金プラン) [東京電力]

2018-08-09

iBeacon/Raspberry Pi による室内移動体位置監視モデル 2 ~ RSSI・距離補正と三点測位について ~


お知らせ

 屋内測位システム『TPC_IPS Ver1.0』を2022/4/1にリリースしました。

 同製品に関する質問またはデモを希望されるお客様はこちらよりお申し込みください。

 同製品のカタログのダウンロードはこちらをクリックしてください。

 尚、外部のIPS/RTLSと連携して動作するIPSアプリケーション・テンプレート『QuickIPS』及び 『TPC_IPS Web API』 も順次リリースを予定しています。


 前稿(18/4/10)では室内移動体位置監視モデルに関する概要について記しました。本モデルは倉庫、施設、工場のような環境で、移動する多数のモノや人に iBeacon(以下、ビーコン)を取り付け、それらモノや人の位置を把握することを目的とします。

図1
 図の端末(ピンク)はビーコン(青)からの信号を検知し、信号のRSSI(後述)から距離を算出します。端末⇔ビーコン間の距離が各円の半径となります。各端末はビーコンとの距離(半径)しか算出できないため、複数の端末の距離データを使用してビーコンの位置を算出します。ビーコンが移動すると、最小の半径を持つ端末(TOP3)が替わるため、替わった端末(図ではPi12/15/16)が算出する距離データにより、その移動先の位置(After)が算出されます。

 今回はビーコンの位置算出の要になるRSSIに関して小社で行ったテストについて記します。

RSSIと距離について

 RSSI(Received Signal Strength Indicator) はビーコンから発せられる信号の強度を示す数値で、ビーコンから離れるに従ってその強度は規則的に減衰します。ビーコン信号を受信する端末 ― ここでは Raspberry Pi(以下、RP、監視端末、端末と呼ぶことがあります)― はビーコン信号のRSSIを測定し、その減衰度により自身とビーコン間の距離を算出します。この信号強度は理論的には距離の二乗に反比例して減衰するのですが、実際には様々な電波干渉があるため、ビーコン⇔端末間の距離が長くなればなるほどRSSIのばらつきは大きくなり、その精度は劣化していきます。

図2
例:ビーコン信号強度グラフ(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 等を使用する方が良いと思います。

図3
システム構成図

プロトタイプについて

 今回テストで使用したプロトタイプは tpcbeaconhost.js、tpcbeaconinfo.js と tpclocation.js で node.js 下で動作するアプリケーションです。これらは相互に連携しながら各ビーコンの信号取得、端末⇔ビーコン間の距離算出、補正、データベース更新を担います。
表1
モジュール名 用途
 tpcbeaconsampler.js 端末にインストール。アプリケーションサーバからのリクエストに応じて、検知したビーコン信号を基にデータを作成し、アプリケーションサーバに送信する。
 tpcbeaconinfo.js ・アプリケーションサーバ上に配置。各端末に対してリクエストを送信。端末から受信したデータを必要に応じて再加工し、データベースを更新する。
・端末のリクエストに応じて、端末やビーコンに関する情報を送信する
 tpclocation.js ・アプリケーションサーバ上に配置。tpcbeaconinfo.js が記録したデータベース上の情報を基に、距離(半径)の補正やビーコン位置の算出を行う。
plotly.jsを利用した端末とビーコン位置のプロット(下図10参照)。
・上記の処理はアプリケーションサーバ上のスケジュール、またはユーザのリクエストに基づき実行。

RSSI 測定テスト

 ビーコンメーカーのAplix社は RSSI に影響する要因として、以下を上げています[1]
  1. Beaconの送信出力、アンテナのゲイン、放射パターン
  2. 受信側スマートフォンの感度、アンテナの向き等
  3. スマートフォンOS内の処理(Bluetoothスタックの振る舞い他)
  4. 周囲環境(建材、人体等)による反射・吸収・回折

 このように RSSI値は様々の要因に影響を受けるため、端末が信号を受信しても、理論値と実測値は異なります。以下のテストは、RSSIがどの程度環境の影響を受けるのかをテストし、「考察」では補正方法についても簡単に記載しています。

※Apple社ビーコン補正の適用について
 以下の文章中、「Apple社ビーコン補正」が「有」或いは「無」といった表記をしていますが、これはビーコン導入時に iPhone等によりビーコンから1m離れた地点で RSSI を測定し、その測定値の平均により補正を行ったか、行わなかったとを意味します。このビーコン補正はApple社の Getting Started with iBeacon (PDF)の「Calibrating iBeacon」の項に基づき行っています。
 ※ RSSI の距離変換
 RSSIは信号強度を対数で示した数値ですが感覚的に把握し難いため、本稿では多くの場合、距離に変換して表記しています。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. Apple社 ビーコン補正:有

結果

 以下の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
  4. ビーコンと端末は固定してあり、移動しない。
  5. テスト中、ビーコンと端末の間、またはその周辺の人、モノの移動は最小限にする。
  6. Apple社ビーコン補正:無
凡例

* 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. Apple社ビーコン補正:無

結果

※上のグラフで[0.2,0.25]は、距離が0.2m~0.25mと測定されたAplixビーコンが3台あったことを示す。

表3
 AplixGimbal
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とそれに基づく距離が大きく異なることが判りました。
以下ではこの誤差を補正できるか否かを小社で開発したプロトタイプシステムを使用して検証します。



RSSI・距離補正 (18/09/24加筆)

上述のように、RSSI 或いはRSSIから算出されるビーコン⇔端末間の距離は、そのままでは信頼性の低いものです。三点測位等によりビーコンの位置(座標)を取得するには、この距離を補正し、精度を上げる必要があります。

Apple社ビーコン補正

 上述のようにApple社のドキュメント「Getting Started with iBeacon (PDF)」に「Calibrating iBeacon 」の一項があり、ここに重要事項として RSSI の補正方法が記述されています。これによると、
  • iPhone等をビーコンから1m離し、ビーコン信号を最低10秒間測定。測定に際しては当該デバイスを縦向きし、(手のひら等で)上半分を遮らないこと。
  • 図のように、デバイスとビーコンとの距離を等間隔に保ちながら、30cmのライン上でゆっくりと上下に動かす

Apple社の上記ドキュメントより
  • 上記の測定の実行中に rssi の測定値を収集し、その平均値をベンダーが提供する方法によりビーコン本体に登録する
とあります。
 この方法は、ビーコンが固定されていてiPhone等のデバイスが移動する環境では良く機能するのかも知れませんが、小社が想定する端末が天井などの高い位置に固定され、その下に多数のビーコンが配置される環境では良い結果が得られませんでした。

 また、ビーコンの数が多いとその測定値を集計・平均し、登録する作業もかなりの時間を要します。

補正テストの環境

 今回小社では下図のような補正テスト環境を用意し、端末とビーコン間のRSSIを測定し、補正テストを実施しました。当初は端末(図のa~i)の間隔を10mと想定していたのですが、その場合、測定値と実際の距離の乖離が大きく、今回は端末の間隔を各4mにしました。
図のように端末は壁のすぐそばに設置されていたり、壁により隔てられており、環境は悪条件に属すると思います。ただ実際の運用環境も良い条件に無いことが想定されるため、悪条件下でのテストを実施しました。

図5:テスト環境
凡例:
a~i:Raspberry Pi 端末 ― ビーコンを探知し、RSSIを測定
Fix:固定ビーコン、端末下1mに固定された補正用ビーコン
B:測定対象となるビーコン
青点線:壁または窓、電波伝搬の障害となる


使用デバイス


ビーコン: Aplix 社製 MyBeacon 汎用型ビーコン  ― テストを単純化するため、今回は他社の製品を使用していません。
監視端末: Raspberry Pi Zero W/WH/3B/3B+ 
その他:上図3のシステム構成に準じる


次に小社で考案した3つの補正方法を提示した後、各方法毎にテスト結果を記します。


DBビーコン補正

 前述のように Apple社の補正方法は今回のモデルでは今一つの結果で、測定値(平均)の登録にも労力と時間を要します。本補正方法は、このApple社の方法を応用したものです。
 まず下図のように、円卓テーブルの円周上にビーコンを並べ、Rapberry端末から各ビーコンの距離が1mとなるように配置します。その後スキャンを数十秒から数分行い、次に円を90度回転させて再スキャン、さらに90度回転してスキャンというようにスキャンを計4回行い、ビーコン毎に平均した値をデータベースに登録します。

図6:DBビーコン補正の事前スキャン


 ビーコンと端末間の距離(d)は以下の計算式を使用して求めますが、式内の RSSI@1meter がデータベースに登録された各ビーコンの値となります。
 
式1:RSSIより距離を算出する式

 Apple社のように1台1台、ビーコン本体に値(RSSI@1meter)を登録するのではなく、一括スキャンし、一括してデータベースに登録ができ、ベンダーのサービスに依存しない点が本方法のメリットです。

注:RSSI@1meter は、TxPower とか Measured Power 等と呼ばれていて、名称は統一されていません。1m地点でのRSSIを TxPower と呼ぶのは、やや違和感があります。


端末補正

 上述のテスト2では、ほぼ同一条件で1m離れたビーコンの信号を測定したにも関わらず、端末によってその算出距離にはかなりの差がありました。また、端末の個体差だけではなく、時間帯、設置場所によっても電波は様々な影響を受けます。そこで配置した端末から1mの場所に補正専用のビーコン(固定ビーコン)を配置し、実際の距離である1mを測定距離で除して係数化します。例えば、端末Aでこの固定ビーコンのRSSIを測定し、そこから算出された距離が0.5mであれば、1m÷0.5mで 2 が端末係数となります。この値を端末Aが受信したすべてビーコンの信号対して適応します。

領域補正

 3つ目の補正方法が領域補正です。上述の式1に n という係数がありますが、この n は伝搬損失係数(Path-loss index)と呼ばれ、理想的な環境では2となります。しかし、電波は干渉、減衰、回折、反射、吸収の影響を受けるため、端末とビーコンの配置場所により変動します。
 式1を展開して n を求めると以下のようになります。
式2:伝搬損失係数 n の算出式

 本補正法では、この n を使用して補正を実施します。
 まず、アプリケーション(tpclocation.js)は、図のように近接する2つの固定ビーコン間で n を求めます。

図7



 次に各端末(tpcbeaconhost.js)がスキャンにより取得した未補正のRSSIを使用し、ビーコンに最も近接する端末(No1端末、図ではF1)を特定します。No1端末を特定すれば、その近接端末(図のb、d、f、h)が特定できます。端末bからビーコンBまでの距離(d)は、上記の式1を使用して以下のように求められます。

式3

 同様に端末d、f、hからビーコンBまでの距離も求めます。
 尚、三点測位を行う場合は、最も距離の短い3つの端末の座標と距離(半径)データを使用します。

注:
No1端末の対角線上にある端末のデータの使用、及び三点測位については、稿を改めて述べたいと思います。

補正テストの結果

 以下が上記3つの補正方法による測定結果です。テスト環境は図7の通りで、各端末の直下に測定対象となるビーコンBを3つから4つ配置しています。本来であれば、ビーコンを分散させるべきですが、テスト結果の評価を容易にするために、このように配置となっています。データは実際の距離が1mと4mとなるものを抽出し、平均値で示しています。

表4
実際の距離未補正DBビーコン補正端末補正領域補正
1m0.621.952.322.68
4m2.758.0518.861.59E+28

 残念なことに、未補正のデータが一番実際の値に近いという結果です。結果が悪いのは上述のようにデバイスが壁に近すぎたり囲まれていて、干渉が大きく影響しているためと思われます。また、「DBビーコン補正」は  RSSI@1meter の値の取得時の端末と場所が実際の端末(a~i)と異なることも要因と思われます。「端末補正」は RSSI@1meterを基に算出した端末係数を異なる距離に存在するビーコンに適用することに無理があるかもしれません。

 領域補正については指数表示になるほど実際の距離とかけ離れています。これは伝搬損失係数 n に異常値が発生しているためです。そこで、nが異常値となった等いくつかの条件下では、領域補正を適用せず、未補正の数値を使用するようにアプリケーションを変更した結果が以下となります。

表5
実距離未補正DBビーコン補正端末補正端末補正
(未調整)
領域補正
(調整有)
1m0.621.952.322.680.98
4m2.758.0518.861.59E+283.63

 調整により実際の距離に大分近くなりました。

二円指向三点測位(19/02/07加筆、19/05/10下表図等一部修正)

 通常の三点測位では、下図の「理想」のように3円が交差する状態で、以下の方程式によりその接点を求め、さらにその幾何中心を以て目標物(ここではビーコン)の位置とします。

式4
r1 =  (x - x1)2 + (y - y1)2
r2 =  (x - x2)2 + (y - y2)2
r3 =  (x - x3)2 + (y - y3)2


図8

 しかし、当方のテストではRSSI・距離の補正後も「理想」のようきれいに3円が交わることは少なく、補正されたデータでプロットしても、様々なパターンが出現します。上図の「現実」がその例で、プロットパターンは当社が認識している範囲で15になります[2]。このような3円がきれいに交差しないプロットパターンの場合、「単純に3円の交点から幾何中心を求める」だけのプログラムは破綻する(またはエラーを返す)ことになります。
 小社でも当初は上記の式4を含め、15のプロットパターンに対応した式をそれぞれ用意し、ソースコードに落とそうとしたましたが、ソースを書き始めると工数的に厳しいことがわかりました。次に発生頻度の高いプロットパターンにのみ対応させ、発生頻度の低いパターンについては「汎用処理」をなんとか捻り出すことにしました。汎用処理は後回しにして、いくつかのプロットパターンに対応したテストプログラムを用意して実行しましたが、ビーコン座標の算出の結果は良いものではありませんでした。
 そこで次に考えた苦肉の策が、上記「汎用処理」とその拡大適用(すべて或いは多くのプロットパターンに適用する、という趣旨)で、これが以下の「二円指向三点測位」です。

二円指向三点測位

 このテストモデルでは、碁盤の目状に Raspberry端末を配置します。各端末はビーコン信号をスキャンしてRSSI等の情報をデータベースサーバへ送ります。サーバはビーコン⇔端末の距離(半径)が短いと認識した最上位1~3の端末を特定します。端末が増えた場合でも、上位3つの端末の情報を使用します。

図9


 例えば、あるビーコンとの距離が最も短かった端末がC1、2番目がC2、3番目がC3だったとします。この時、サーバはビーコンのx座標を求めるにあたって、C3端末を考慮せず、C1端末とC2端末の情報のみで算出します。算出方法は下表の通りです。

表6
状態 距離区分 x 座標の算出時の条件 x座標算出式 イメージ
1.分離 A.遠隔 2円が一定の距離を超えて分離し、C1の半径(C1r)がC2の半径より小さい C1x + C1r
B.近接 2円が一定の距離以内で分離している C1x + d/2
2.交差 C.C2円周中心内 2円が交差し、C2の円周がC1の中心を超えることは無い C1x +C1r- d/2
 
Ce.C2円周中心内・極小 上記Cと同条件で且つ、C2半径に比したC1半径が一定の比率以下(C1の半径が非常に小さい) C1x+c1r
D.C2円周中心外 C2の円周がC1の中心を超える C1x
3.包含 D.C2円周中心外 C2がC1を包含する C1x  

 y座標についても上表のルールに準じて、C1 と C3 を使用の座標とで算出します。


二円指向三点測位のテスト

 テストの際は、図9のように端末4台とビーコンを配置しました。図9の「B」の地点には、固定ビーコンも含めて4~5台のビーコンがあり、固定ビーコンを含め計40台のビーコンを使用しました。端末と同位置に見えるビーコンは、端末の直下1mに配置しています。図7のように端末とビーコン間には壁や窓があり、電波はかなり悪い状態と推定されます。
 下図が上述のロジックに基づき作成したプログラム「tpclocation.js」 により端末が送ってきたデータを補正・描画したものです。が「二点指向測位」による算出された座標、■が実際の座標です。

図10

端末位置(各円の中心)と端末からビーコンまでの距離を tpclocation.js により表示


凡例
Teminal: 使用した端末名
x: x座標,  y: y座標
Distance: 端末からビーコンまでの距離(半径)
Acual(■): ビーコンの実際の位置
Calc.(): 二円指向三点測位に基づき算出されたビーコンの位置
Gap: | Actual.x - Calc.x | + | Actual.y - Calc.y | 、誤差(Distance error)


結果

40台のビーコンを二円指向三点測位した結果は下記の通りです。

平均誤差 (Average distance error):2.36m
最大誤差 (Maximum distance error):6.03m


 さて、今回提示した二円指向三点測位は端末を正方形状に配置することを前提にした測位モデルでしたが、次回は正方形のセンタに端末を付加することにより、測位精度の向上を目指します。このセンタ端末と他の端末には角度が付くため、二円指向三点測位は拡張することになります。
 また、端末間の距離を4mから、8m、16m、32mとしたとき、どの程度の誤差で測位できるのかも検証します。 詳しくは[次稿]をご覧ください。




(土屋)


参考サイト:

^[1]Beaconを使った近距離測位の特性[Aplix社]
^[2]Intersection of 3 circles calculator (13のプロットパターンを表示)
Talk:Trilateration/Archive 1 (Wikipedia で「Trilateration」 が「Multilateration」に統合された理由、C++のソース等)

IPS関連のBlog記事

土屋企画のIPS製品について/IPS product of TPC