当社の屋内位置測位システム『TPC_IPS』 はビーコン信号をサーバ上の位置測位エンジン（TCOT）により解析し、算出された各ビーコンの位置情報をデータベースに保存します。ユーザは適時クライアント機からデータベースにアクセスして位置情報を引き出し、フロアマップ等のフロントエンドアプリケーションで利用します。この方式はクライアントがサーバに情報を要求するPull式となっています。
一方、サーバ側からクライアントにデータを送り付けるPush式のシステムも存在します。今回、『TPC_IPS』の位置測位エンジン（TCOT）で算出した位置情報をUDPでネットワークにブロードキャストし、クライアントのフロアマップを自動更新する処理を実装してみました。
サーバとクライアント間のモジュール構成を図示したのが以下です。
サーバには tcot_sender.py というプログラムが常駐していて、これがTCOTを呼び出して位置情報を取得、これを python socket によりUDPでブロードキャストします。
一方、クライアント上ではtcot_receiver.pyが上記のUDPを待ち受けしていて、UDP データを受信するとデータ加工などの必要な処理を行います。
フロントエンドアプリケーションの『QuickIPS』はフロアマップ上にビーコンの最新の位置を表示しますが、QuickIPS は FileMakerで開発されており、FileMaker自身にはソケット通信の機能がないため、tcot_receiver.py から直接データを取得することはできません。
そこで tcot_receiver.py と QuickIPS 間でソケット通信を可能にするため tcot_listener.html というファイルを用意し、フロアマップのレイアウトにWebビューア*を配置してこのhtmlファイルを埋め込みます。tcot_listener.html は WebSocket を作成すると共に addEventListener を使用してtcot_receiver.pyからの受信を待ち受けます。 受信を感知すると PerformScript()によりFileMakerのスクリプトを実行して QuickIPS のフロアマップを更新します。
*WebビューワはFileMaker Pro のレイアウトに Web ページを直接表示する機能。
以下、今回実装した UDP Push式の長短をまとめてみました。
UDP Push方式のメリット
- TCP 通信に比べ、データ転送速度が速い
- サーバ負荷の低減 特にユーザ数が多い場合
- システム構成の柔軟性
- リアルタイム性(オーバーヘッドが少ないため、クライアントアプリの実行速度の向上)
UDP Push 方式のデメリット
- TCP 通信に比べると送信データが保証されないため、データの欠損（パケットロス）が生じることがある。
- UDP通信の接続確認およびデータ受信確認の処理が面倒
注：
TPC_IPS ver1.0は UDP Push に対応していません。今後のリリースでの対応を予定していますが、仕様は予告なく変更されることがあります。
(亀)
IPS関連のBlog記事
- iBeacon/Raspberry Pi による室内移動体位置監視モデル1 ～ 概要 ～
- iBeacon/Raspberry Pi による室内移動体位置監視モデル 2 ～ RSSI・距離補正と三点測位について ～
- iBeacon/Raspberry Pi による室内移動体位置監視モデル 3 ～ 二円指向三点測位の拡張 ～
- 東京ドームのような広い場所で少ない受信機によりビーコンのおおよその位置を推定する
- 機械学習によりIPSの位置測位精度を改善する
- IPSのテストベッドをつくる際のTIPS ― デバイスの保護とスマート電源
- FileMaker用IPSアプリケーション・テンプレート ― QuickIPS ―
- 人・モノの動きをマップ上で可視化するオブジェクトトラッキング
- 位置情報をUDPで送信 ― TPC_IPS/QuickIPSの拡張
土屋企画のIPS製品について/IPS product of TPC
