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 測定テスト
RSSI・距離補正
二円指向三点測位
1. 二円指向三点測位
2. 二円指向三点測位のテスト
IPS関連のBlog記事

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]。

Beaconの送信出力、アンテナのゲイン、放射パターン
受信側スマートフォンの感度、アンテナの向き等
スマートフォンOS内の処理(Bluetoothスタックの振る舞い他)
周囲環境(建材、人体等)による反射・吸収・回折

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

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

目次へ戻る

テスト1 1つのビーコンのRSSIを24時間測定

目的

　固定した1つの端末と1つのビーコンを使用し、RSSIの精度、時間帯による変動をチェック

条件

1つのビーコンを1つの端末で24時間測定。
端末による1回のスキャン時間は5秒間。24時間で約1万7千のスキャンを実施。1回のスキャンで収集されるデータは平均34件、RSSIはスキャン毎に平均している。また、下図でRSSIは距離(m)に変換している。
ビーコンと端末間の実際の距離：4.5m
ビーコンと端末は固定してあり、移動しない。
テスト中、ビーコンと端末の間、またはその周辺の人、モノの移動は最小限にする。
Apple社ビーコン補正：有

結果

　以下の2つ図は、データベースに記録されたデータをプロットしたもの。

【散布図1：時間経過と計測距離の変化】

RSSI はメートルに変換し縦軸に、横軸は計測時間

横軸に距離、縦軸に発生件数を棒グラフ化。

平均(AVG)：2.75m
標準偏差(SD) ：0.88m
最大(MAX)：9.96m
最小(MIN)：0.93m

考察

端末⇔ビーコン間の実際の距離は4.5mだが、測定値では2.75m（平均値）で、かなりの乖離がある（実際の距離とは異なる）。また、最大値と最小値の差も大きい。
日中は距離の偏差が大きく、夜間に小さい。これは夜間は人間の発するWiFi等の電波による干渉が少ないためと推定される。また、日中は夜間に比し、値が上振れする。
以上のことより、距離の精度を上げるためには、時間に連動した応じた補正が必要。

目次へ戻る

テスト2　複数端末で複数ビーコンのRSSIを測定

目的

端末の個体差はどの程度あるのか
BLEデバイスが異なると、RSSIに顕著な違いは発生するのか

条件

各端末によるビーコンスキャンは10秒間、1回のみ。
各端末が収集したデータは平均で50件弱。RSSI(表のaveRssi)は平均値。また、下表でRSSIを距離(Ave)に変換している。
端末(下図のPi1、Pi5-Pi8)から1m(Dist)の所にAplix(AP)10個とGimbal(GI)20個を配置。ビーコンは多数のため、端末との距離をできる限り1ｍに保つため格子状のプラスチックケース等に収納した。尚、Pi5 は 3B にBLEドングルを装着したもので、内臓BLEは無効化してある。
図4
ビーコンと端末は固定してあり、移動しない。
テスト中、ビーコンと端末の間、またはその周辺の人、モノの移動は最小限にする。
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.：総平均

考察

同種の端末で同環境でテストしても、RSSIの値に差がでる。また、Pi5は BLEドングルを使用しているが、他端末の値との差が大きい。
上述のビーコン補正を行わないと、実際の距離は1mであっても計測されるRSSIに対応する距離は全くかけ離れた値になることがある。
以上、端末間でもRSSIの値に差異があるため、端末単位の補正が必要。

目次へ戻る

テスト3　ビーコンとメーカーによるRSSI(距離)の差異

目的

ビーコン間、メーカー間でどの程度RSSIに差があるのかを調査

条件

ビーコンはAplixを20個、Gimbalを49個、1つの端末を使用。ビーコンを丸テーブルの円周上に配置。その上部に天井から吊るした端末と各ビーコン間の距離が1mになるようにする。
端末によるキャン時間60秒×5回を1セット。1セット終了後90度テーブルを回転させ、計4セット（60秒×5回×4セット）を実行。これは端末アンテナとビーコンの位置などにより、RSSIの値が異なることを想定し、値を丸めるために実施。
計20回のスキャンで端末が受信したデータ数は1ビーコン平均で約3600件。RSSIはスキャン毎に平均。下図ではRSSIを距離(m)に変換している。
ビーコンと端末間の実際の距離：1m
スキャン中、ビーコンと端末は固定してあり、移動しない。
テスト中、ビーコンと端末の間、またはその周辺の人、モノの移動は最小限にする。
Apple社ビーコン補正：無

結果

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

表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件

考察

ビーコン個体についても計測値に差があり、最小値と最大値については3倍～4倍もの差がある。
AplixとGimbalの平均値で約2倍の差がある。
以上のことから、個々のビーコンに対する補正と、ベンダー（ビーコンシステム）別の補正が必要。

　以上、時間帯、端末個体、端末種類（ビーコンシステム）、ビーコン個体、ビーコン種類（ベンダー）により、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と想定していたのですが、その場合、測定値と実際の距離の乖離が大きく、今回は端末の間隔を各4ｍにしました。
図のように端末は壁のすぐそばに設置されていたり、壁により隔てられており、環境は悪条件に属すると思います。ただ実際の運用環境も良い条件に無いことが想定されるため、悪条件下でのテストを実施しました。

図5：テスト環境

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

使用デバイス

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

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

目次へ戻る

DBビーコン補正

　前述のように Apple社の補正方法は今回のモデルでは今一つの結果で、測定値（平均）の登録にも労力と時間を要します。本補正方法は、このApple社の方法を応用したものです。
　まず下図のように、円卓テーブルの円周上にビーコンを並べ、Rapberry端末から各ビーコンの距離が1ｍとなるように配置します。その後スキャンを数十秒から数分行い、次に円を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ビーコン補正	端末補正	領域補正
1m	0.62	1.95	2.32	2.68
4m	2.75	8.05	18.86	1.59E+28

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

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

表5

実距離	未補正	DBビーコン補正	端末補正	端末補正 (未調整)	領域補正 (調整有)
1m	0.62	1.95	2.32	2.68	0.98
4m	2.75	8.05	18.86	1.59E+28	3.63

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

目次へ戻る

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

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

式4

r₁² = (x - x₁)² + (y - y₁)²

r₂² = (x - x₂)² + (y - y₂)²

r₃² = (x - x₃)² + (y - y₃)²

図8

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

二円指向三点測位

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

図9

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

表6

状態	距離区分	x 座標の算出時の条件	x座標算出式
1.分離	A.遠隔	2円が一定の距離を超えて分離し、C1の半径(C1r)がC2の半径より小さい	C1x + C1r
1.分離	B.近接	2円が一定の距離以内で分離している	C1x + d/2
2.交差	C.C2円周中心内	2円が交差し、C2の円周がC1の中心を超えることは無い	C1x +C1r- d/2
	Ce.C2円周中心内・極小	上記Ｃと同条件で且つ、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

目次へ戻る

2018-05-24

PostgreSQL 10 インストール時の不具合解消方法

Windows Server に PostgreSQL 10 インストール時に「Error with Configuration or permission 」という警告が出る場合の対処方法

　Windows Server 2012 環境に最新版の PostgreSQL 10 (10.4) をインストールしてみたのですが、途中で以下の警告メッセージが表示されてしまいました。

PostgreSQL 10 インストール時に発生した警告メッセージ

　警告ダイアログには、「ログを見ろ」とあったので確認してみたところ、権限設定で失敗していた模様です（文末参照）。

　そこで、以下の方法で不具合の対応をしてみました。
　同様の不具合でお悩みの方はダメ元で試してみるとよいかもしれません。

　※インストール失敗理由については文末の「不具合の原因」のセクションをご覧ください。

PostgreSQL 10 インストール失敗の対応方法

上記の警告メッセージが発生してもいったんは最後までインストールする
内部的にはインストールはエラーとなるため、このままでは PostgreSQL サーバの起動はできません。
コントロールパネルの「プログラムのアンインストールまたは変更」から PostgreSQL をアンインストールする
アンインストール後に残ったインストールフォルダより、\data\pg10 までたどり、pg10 フォルダのセキュリティより、Users グループに「変更」権限を付与する

PostgreSQL 10 の \data\pg10 フォルダの Users アクセス許可に「変更」権限を付与
もう一度、Postgres 10 をインストールして成功すれば終了

不具合の原因

　結論から述べると、PostgreSQL 10 を Windows にインストールした際に、以下のメッセージが出た場合は、権限設定エラーが発生した可能性が高いということになりました。

「Problem running post-install step. Installation may not complete correctly
Error with configuration or permissions. Please see log file for more information.」

　以下が、不具合の調査結果になります。

1. インストールログファイルの特定
　PostgreSQL 10 のインストールログは、PostgreSQL 10 インストールディレクトリ直下の logs フォルダにあります。この中の PostgreSQL-installLog.log を確認します。

2. PostgreSQL-installLog.log の中から "Error with configuration or permissions" という文字列を検索してみます。

　エラー文字列の付近を調べてみると、どうやらデータベース初期化時にエラーを起こしていたらしいことがわかります。

Initializing Postgres DB with:
E:\PostgreSQL\pg10\bin\initdb -U postgres -A md5 --encoding UTF8 -D "E:\PostgreSQL\data\pg10" --pwfile="E:\PostgreSQL\pg10\.pgpass" > "E:\PostgreSQL\data\logs\pg10\install.log" 2>&1 ERROR: Unable to Initialize PG. see logfile: E:\PostgreSQL\data\logs\pg10\install.log
Error running init-pg10
Script stderr:
Program ended with an error exit code

Error with configuration or permissions. Please see log file for more information.
Problem running post-install step. Installation may not complete correctly
Error with configuration or permissions. Please see log file for more information.

3. エラーが発生したコマンドをコマンドプロンプトから走らせてみる

　ログテキスト（赤色）より、ログファイルへのリダイレクト部分を取り除いたコマンド文字列を走らせてみました。

E:\PostgreSQL\pg10\bin\initdb -U postgres -A md5 --encoding UTF8 -D "E:\PostgreSQL\data\pg10" --pwfile="E:\PostgreSQL\pg10\.pgpass"

　すると、以下のように \data\pg10 のディレクトリの権限を変更しようとして Permission denied が返されたことがわかりました。

PostgreSQL コマンドによるデータベース初期化時に Permission denied が返る

4. Users グループに「変更」権限を与えてみる
　権限エラーということで、pg10 フォルダの Users グループに「変更」権限を追加します。
　上記のコマンドプロンプトのスクリーンショットの解説では、以下の記述があります。

データベースシステム内のファイルの所有者は"Administrator"となります。このユーザがサーバプロセスも所有する必要があります。

　インストール実行時の Windows ユーザは Administrator でしたので、権限の書き換えは問題なくできると思われたのですが、実際はそのようにならなかったため、Administrator がデフォルトで所属している Users グループを採用しました。
　恐らく、他ユーザでインストール中にもこの方法で対応できると思います。

PostgreSQL 10 の \data\pg10 フォルダの Users アクセス許可に「変更」権限を付与

5. 先ほど失敗したコマンドをもう一度走らせてみる
　3. のコマンドをもう一度走らせます。
　ご覧のとおり、エラーが解消されましたね。

PostgreSQL コマンドによるデータベース初期化成功

　よって、今回の不具合の原因は data\pg10 フォルダの権限不足によるものでした。

※ Everyone を追加してから、フルコントロール権限を割り当てても同様に動作しますが（実験済み）、Everyone を重要なフォルダに割り当てたり、高度な権限を与えたりすることはサーバのセキュリティリスクを高めることになりますのでお勧めはしません。

参考リンク：
Re: BUG #14541: Getting error while installation

(亀)

2018-04-10

iBeacon/Raspberry Pi による室内移動体位置監視モデル1 ～概要～

[English page]

お知らせ

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

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

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

本稿では Raspberry Pi 端末（以下、「端末」、「監視端末」と呼ぶことがあります）によりビーコンをスキャンし、その位置を測位する「室内移動体位置監視モデル」について考えます。このモデルは製品ベンダーによって、あるいはシステムの用途によって、「屋内測位システム」、「資産管理システム」、 Indoor Location (Tracking) System、Indoor Positioning System (IPS)、Asset Tracking System、Realtime Location System(RTLS) 等と呼ばれています。　当ブログではこのモデルを示す用語として IPS を主に使用します。

サブモデル
1. ［コラム］ドローンフライト制御モデル
システム概要

三点測位
考慮すべき課題

RSSI の精度
三点測位の問題

2018年4月以降の改良点とIPS市場の動向

測位方法
BLE5.1 AoA/AoD
UWB

IPS関連のBlog記事

サブモデル

　移動するモノの位置を測位するシステムモデルはその要求属性によって、サブモデルに分かれます。

要求属性	属性説明	値
測位対象数	測位対象が多いか、少ないか	少数｜多数
移動頻度	測位対象の移動頻度	高頻度｜低頻度
移動速度	測位対象の移動速度	高速｜低速
測位精度	要求される測位精度	高精度｜低精度
リアルタイム性	測位要求から測位実行迄の時間	リアルタイム｜非リアルタイム*1
測位対象	測位対象となるモノ	ビーコン｜携帯端末
Appデバイス	測位結果を表示するデバイス	管理端末｜携帯端末*2

*1：非リアルタイムの場合、約1分迄の時間差は許容する
*2：管理端末は主にPC、携帯端末も可

　サブモデルには以下のようなものがあります。

屋内ゲームでプレイヤーの持つスマホに自身や他のプレイヤーの位置を表示する
属性：少数｜高頻度｜高速｜高精度｜リアルタイム｜携帯端末｜携帯端末→ 屋内GPSモデル
ホッケー等屋内スポーツで、選手の位置をPC等に表示しする
属性：多数｜高頻度｜高速｜高精度｜リアルタイム｜ビーコン｜携帯端末 → ホッケーモデル（フィンランド Quuppa 社の動画）
病院、介護施設で患者や入居者の位置をスタッフが把握する
属性：多数｜高頻度｜低速｜低精度｜非リアルタイム｜ビーコン｜管理端末→病院モデル
工場の組立工程にある製品の位置を管理する
属性：多数｜高頻度｜低速｜低精度｜非リアルタイム｜ビーコン｜管理端末→工場工程モデル
倉庫や保管場所にある製品の位置を把握する
属性：多数｜低頻度｜低速｜非リアルタイム｜ビーコン｜管理端末→倉庫モデル

　サブモデルにより IPS の仕様や運用方法も変わってきます。当社で開発中の TPC_IPS は上記の3~5のサブモデルを利用対象としています。

目次へ戻る

［コラム］ドローンフライト制御モデル

　市販のドローンの多くはGPSを搭載しており、屋外では自身の位置を認識しますが、GPS信号の受信状態が悪い或いは受信不能な屋内、ビル近辺、谷間等では、GPSは機能しません。　このような場合、IPSによりドローンの位置を把握し、フライトを制御するケースが考えられます。これによりプログラムにより制御されたドローンが物品を輸送したり、深夜に無人のビルや工場を巡回監視したり、撮影することができます。

　ただ、iBeacon(BLE4ビーコン)による IPS はその測位誤差が1メートル以上と大きいため、オフィスなどでのドローン制御は難しいと思います。　
　この点、BLE5.1AoA対応ビーコンや Ultra Wide Band(UWB)タグを用いたシステムであれば、測位誤差が1m～10㎝までに抑えられるため有利です。

　IPS の導入にあたっては、そのシステムがどの程度の測位精度を求めるのか、という点が重要です。

目次へ戻る

システム概要

　下図のように監視対象とするエリアを正方形で区切り、各正方形の頂点に監視端末（Raspberry Pi、図のピンクのマーク）を配置して、ビーコン信号をスキャンします。図の青いマークがビーコンで、これらが人やモノに取り付けられて移動します。Raspberry Pi の間隔、つまり各正方形の辺の長さは、障害物や人の多い場所や、高い測位精度が求められる環境では狭くします。　逆に障害物や人が少ない場所や、測位精度を重視しない環境では広く取り、端末の台数を減らすことができます。

【図1：Raspberry Pi監視端末の配置】

運用環境では監視端末を正方形状に配置できないことも多い

　各Raspberry Pi は常時ビーコン信号を受信し、その情報をアプリケーションサーバに送ります。サーバはこの情報を基に三点測位を行い、各ビーコンの位置を算出します。

目次へ戻る

三点測位

　ビーコンの位置測位を行う手法はいくつかありますが、今回は三点測位を利用します。
図1の全ての監視端末（Raspberry Pi1 から Pi16）は常時ビーコン信号の読み取り(スキャン)を行っています。　ビーコン信号は発信時に最も強い強度を持ちますが、空間を伝搬するとその距離に応じて減衰していきます。各 Pi はこの信号強度、RSSI(受信信号強度、Received Signal Strength Indication)を取得するので、このRSSIの減衰の度合いからビーコンと端末(Pi)間の距離を算出します。

　下図の「Before (移動前)」の所には端末 Pi2、Pi5、Pi6 を中心とする円がありますが、それぞれの円の半径がビーコン迄の距離となります。三円測位では円の円の交わった点、あるいは3円が重なったエリアの中心をビーコンの位置であると推定します。 Pi2、Pi5、Pi6以外の端末もビーコンを検知しますが、最も近接する端末がこの3つの端末であり、近接する端末の RSSI の精度が高いため、この3の端末の円を基にして三円測位を行います。

　次にビーコンが「After」の位置に移動したとします。移動したことにより、距離が最短となる端末は Pi12、Pi15、Pi16 となりました。この時はこれらの最も近接する端末の円（端末⇔ビーコンの距離）を使用して三点測位を行います。

目次へ戻る

考慮すべき課題

　一見簡単にビーコンの位置が特定できそうですが、そこまで辿り着くのは大変です。　その理由は以下の通りです。

RSSI の精度

　RSSI は端末とビーコン間の距離が数十センチの場合は、そこそこの精度で距離を計測できますが、1mを超えるとマルチパス(多重波伝搬)等の影響を強く受け、信号が公式の通りには減衰せず、RSSIに基づき算出した距離は実際の距離とは大きく異なる、ということが非常に頻繁に発生します。

三点測位の問題

　上記のようにRSSIに基づく距離は信頼性が低いため、三円測位の3つの円が交わらず、三円測位が破綻するということも多々発生します。この場合は単にエラーとするだけではなく、代替の手段を考えなければなりません。

　次稿では実際に RSSI を測定し、それから算出される端末とビーコン間の距離と実際の距離の誤差について考えます。さらに、小社が考案するRSSI・距離の補正方法と、三点測位の拡張についても記します。

2018年4月以降の改良点とIPS 市場の動向

　本稿の公開は2018年4月ですが、その後新たな製品や技術がリリースされ、小社でも新たな手法の開発と検証を続けています。最後にこれらについて簡単に触れておきます。

測位方法

次稿(2018/08/09公開)と次々稿(2019/07/12公開)ではRSSIと距離補正や、三点測位を行うプロトタイプを開発してテスト・検証した結果を記しています。しかし、RSSI 及び RSSI に基づく三円測位は測位精度に限界があります。　この点、機械学習を使用した測位は学習を行う手間がありますが、三円測位に比べ測位精度を上げることが可能です。この機械学習による測位精度についても、プロトタイプシステムを作成、テスト・検証を行い記事(2020/12/26公開)を書いています。

BLE5.1 AoA/AoD

2019年1月にBLE5.1 AoA/AoD の仕様が公表されました。これにより、BLE5.1対応端末(センサー)はビーコンの距離に加えて、ビーコンの存在する方向（角度）を取得することが可能になり、測位精度が1m以下になると期待されています。ただ、仕様公開から2年以上経った現在、主要ベンダーからは BLE5.1 対応の発信機及び受信機（センサー）はリリースされていません。

UWB

2021年4月末、Apple社から AirTag が発売され、iPhone 11/12 を使用すれば AirTag の測位を高い精度で行えるようになりました。この測位に使われている技術が UWB という技術で、誤差10㎝の測位が可能と言われています。UWB を使用した IPSシステムには Ubisense や Zebra といった製品が以前から市場にあり、高い評価を得ていますが、大変高価です。海外IT関連メディアは AirTag を "Game Changer" と呼んでおり、今後 UWB を使用した新たな IPSシステムが市場に現れるものと期待されます。

目次へ戻る

（亀）

IPS関連のBlog記事

目次へ戻る

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

2017-12-30

Androidを使用した多数移動体位置監視モデル

　前稿と前々稿では iBeacon を使用した商品の存否確認に関するモデル（定位置ビーコン監視モデル）について記しました。これらのモデルは iBeacon を使用するため、その電波の到達範囲は0ｍ～100ｍ程度であるため、iBeacon（あるいは iBeacon を取り付けた商品）がその範囲を超えて出ていってしまうと、当然のことながらビーコン監視端末は iBeacon の存在を認識できなくなります。
　今回は前二稿とは趣を変え、モバイル端末を物品に取り付けることによってその位置を適時把握するモデルを考えるとともに、そのモデルに則したプロトタイプを作成・試用してみました。

多数移動体位置監視モデル

　本モデルでは、数十～数百、数千の移動する商品、物品、人などの物体にモバイル端末を取り付け、地図上にその所在地を表示しています。

　下図のように、モバイル端末のインターネット接続にはMVNOが提供する移動体通信網を使用し、端末はGPSにより得られた自身の位置情報をアプリケーションサーバ経由でDBサーバに送ります。DBサーバは送られてきた端末の位置情報を保存します。また、各端末の位置の地図上表示も、PC等のブラウザからアプリケーションサーバを介して行います。

図1 ― モデル概要

通信端末について

　当初、上図端末には Raspberry Pi 等のシングルボードコンピュータを使用する予定だったのですが、検討を進めていくうちにコスト増のモデルになり得ることがわかりました。

　具体的には、まず、ラズパイにSIMドングルやGPSモジュール（ドングル）を載せる必要が出てくるわけですが、実用面を考慮するとユーザに容易にシャットダウンしてもらうための電源On/Offスイッチ、電源供給が遮断された場合に備え、UPSも準備する必要があります。

　これらのモノは全て自前で調達して設定しなければならないため、価格、性能評価や設定の労力、携帯性、収納性等がネックとなります。ラズパイは途中まで設定やテストを行ったのですが、結局 Android 端末を使用することにしました。
　Android であれば All-in-One で低価格（￥5千前後～）で入手でき、携帯性・耐衝撃性(移動時にコネクタ/ケーブル類が外れる可能性がほぼ無い)に優れ、電源周りで気を遣うことがなく、安定性・信頼性も実績十分です。

今回使用したAndroidフォンとタブレット、OUKITEL社(写真左から3/4番目は￥5千/台で購入できた)

移動体通信会社（MVNO）

　本モデルでは多数の Android 端末を使用してインターネット通信を行うため、通信費用はできるだけ抑制したいところです。最近は格安MVNOの登場で、1GB程度のデータ量であれば月額￥500程度で利用できるので、後述のようなシステム仕様であれば1端末月額￥500で運用可能と思われます。
　ただ、今回作成・テストするプロトタイプシステムでは、IoT 通信に特化したデータ通信サービスを展開する SORACOM を試用してみることにしました。
　SORACOM を採用するメリットは主に2つあります。一つは少ないデータ量の通信では費用を低く抑えられること、もう一つは SORACOM API を通じてSIMを制御したり、通信状況を取得することができる点です。SORACOM の実際の使用感については後述します。

システム構成とプロトタイプ開発

　これまでの経緯より、モバイル端末には Android、モバイル通信には SORACOM を使用することに決めました。アプリケーションサーバ（App Server）とデータベースについては、前者を node.js + express.js、後者を FileMaker Server 16 としました。Google Maps API はアプリケーションサーバが Android から取得した位置情報をもとに住所情報を取得する際、またPC/タブレット等でAndroidの位置を Google Map 上に展開する際に使用します（図2参照）。

図2 ― システム機能概要

ハイブリッドアプリとアプリケーションサーバの仕様と処理分担

　Android の GPS から経緯度情報を引き出すには、Android Studio 等でネイティブアプリを作成するか、HTML5/Cordova 等によりハイブリッドアプリを開発することになりますが、今回は iOS 等への対応も視野に入れ、ハイブリッドアプリを採用することにしました（上図の tpcgeo.apk、以下、tpcgeoアプリ）。tpcgeoアプリはアプリケーションサーバに経緯度情報を送信するだけの単純なモノです。Google Maps API を介した住所情報の取得やデータの加工、データベースの更新といった多くの処理は、アプリケーションサーバ上の tpcgeo_server.js と tpcsql.js（前回記事参照）が担います。
　Android 側にあまり仕事をさせないのは、通信量を抑えるというコスト上の理由と、外部で使用するモバイル端末から送信する情報の量は必要最低限にするというセキュリティ上の理由によります。

プロトタイプのテスト

　上記の仕様に従ってそれぞれのアプリケーションを作成し、Android とアプリケーションサーバに必要なアプリケーションやファイルをインストールした状態で、SORACOM SIM（SORACOM Air/Global plan01s）の導入を行いました。図2のように2つのサーバにも必要なシステムをインストールし、テスト開始です。

まず、データベースを起動し、次にアプリケーションサーバで node.js/express.js 上で動作する tpcgeo-servers.js をコマンドプロンプトから起動します。

図3 ― アプリケーションサーバのプロンプトで tpcgeo-server.js を起動

次に、Android 上で tpcgeoアプリを起動し、位置情報を送信する回数（Requests）と送信間隔（Interval、ミリ秒で指定）を指定します。下図では、10秒間隔で20回、自身の位置情報を送信するように設定されています。“Start”をタップすると、位置情報のアプリケーションサーバへの送信が開始されます。

図4 ― Android でハイブリッドアプリ＝tpcgeo 実行画面

アプリケーションサーバ上の tpcgeo-server.js が Android から位置情報を受信すると、Google Maps API に位置情報を送り、その戻り値として住所情報を取得します。そして必要なデータ加工を行った後にデータベースへの書き込みを行います。これらの処理が成功すと、tpcgeo-server.js を実行するプロンプト画面には以下のような実行履歴が表示されます。

図5 ― tpcgeo-server.js のプロンプト上に表示される実行履歴

　プロンプトに update[OK] が表示されている場合、FileMaker データベースの位置データ（下図のLatitude、Longitude、Altitude等、白地のフィールド）の更新が成功したことを意味します。

図6 ― 端末の位置情報等を表示する FileMaker アプリ
オレンジの部分は SORACOM API から取得する SIMの状態、課金情報等。

　各端末の位置は、PC等のブラウザで Google Map 上に表示できます。

図7 Windows Edge で Google Map 上に表示した各端末
データベースから取得した各端末の位置情報に基づき、Google Maps API を介して地図上に端末をマッピング

　赤地のマーカ（端末名）をクリックすると、詳細がポップアップ表示されます。

端末の所在住所等詳細がポップアップ表示される

SORACOM Global について

　前述のように今回は通信にSORACOM社の提供する SORACOM Air/Global plan01s というサービスを利用しました。本サービスに必要な費用は SIM 1枚当たり、以下のとおりです(2017/12/30現在)。

初期費用(SIM本体含む)：US$5
基本料金：US$1.8/30日
データ通信料：US$0.2/MB

ご覧のように初期費用が約500円と非常に低いため、本サービスは多くの IoT/M2M システムのテスト環境構築には適していると思われます。
　ただ、今回の Android ベースのプロトタイプ・システムに類似したシステムを“常時”稼働させようとすると、通信量が想像以上に発生し、月額￥500 の MVNO に比べると割高になると考えられます。
　その理由は Android OSとその付属アプリが予期しない多くの通信を行うからです。No root タイプの Firewall を導入して不要な通信を遮断・監視しようとしても、Firewall を回避して発生する通信が発生するため、これがかなりの量に及びます（なお、Android の Firewall については、NetGuard の開発者・M66B さんが BBS 上で参考になるレスを書いています）。
　
　では、常時稼働ではなく、限定的に稼働するようなシステムではどうでしょうか？たとえば、Android 端末が 1カ月の 80％は社内や倉庫内にあり、その間通信を必要としないケース、あるいは特定時間帯、特定期間にのみ通信を必要とするケース。これらのケースであれば、SORACOM のほうが割安となる可能性があります。というのは、SORACOM API を使用することにより、特定の時間、あるいは特定の条件下で SIM のサービスを停止させたり、一定の通信量を超過した場合は管理者にメールや SMS で通知を行うシステムを構築できるからです。

（亀）

IoT/M2M関連リンク

FileMaker 16 と iBeacon の適用モデルを考える１ ― 美術館等での展示物案内と倉庫内での商品自動検索
iBeacon の適用モデルを考える２　―　定位置ビーコン監視モデル ― 各商品にビーコンを取り付け、存否を監視する
iBeacon の適用モデルを考える３　―　定位置ビーコン監視モデル（2） ― 各商品にビーコンを取り付け、Raspberry Pi により存否を監視する
Androidを使用した多数移動体位置監視モデル　―　人、トラック、自動車などに Android を取り付け、その所在地を常時監視するモデル
FMクライアントからサーバ上のODBC/node.js経由でデータベースをCRUDする ― IoT/M2M 環境でCRUDを担当する tpcsql.js のFileMaker クライアントでの利用

2017-11-14

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

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

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

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

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

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

tpcsql.js のダウンロード

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

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

注：

cURLを使用するため、FileMakerクライアントは Ver.16 以降が必須となります。
FMSは Ver16　でのみ検証を行っています。

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

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

上記で、[odbcDriver]、[host]、[uid]、[pwd]、[database]フィールドは、FMS16 側から見た場合の設定をあらかじめ入力してありますので、そのまま “Go”で実行できます。
以下のようにクエリ結果が [result]フィールドに戻ってきたら成功です。
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関連リンク

FileMaker 16 と iBeacon の適用モデルを考える１ ― 美術館等での展示物案内と倉庫内での商品自動検索
iBeacon の適用モデルを考える２　―　定位置ビーコン監視モデル ― 各商品にビーコンを取り付け、存否を監視する
iBeacon の適用モデルを考える３　―　定位置ビーコン監視モデル（2） ― 各商品にビーコンを取り付け、Raspberry Pi により存否を監視する
Androidを使用した多数移動体位置監視モデル　―　人、トラック、自動車などに Android を取り付け、その所在地を常時監視するモデル
FMクライアントからサーバ上のODBC/node.js経由でデータベースをCRUDする ― IoT/M2M 環境でCRUDを担当する tpcsql.js のFileMaker クライアントでの利用

2017-09-07

太古の FileMaker システムを延命させる！ ― 後日談

　今年の4月に FileMaker Pro 5.5 を運用する Windows Server 2008 (32bit版、Remote Desktop Serviceを運用）をP2Vにより仮想マシン化するプロジェクトに関する記事を書きました。
　あれから4カ月、先月末、ようやく納品が終わりました。いろいろあってとっても苦労しました、トホホ…　以下、古いFileMakerシステムを仮想マシン化して Hypervisor 上で運用したい、という方の参考に多少ともなれば幸いです。

1. FileMaker Pro 5.5/6を仮想マシン上で運用する

今回、特に問題となったのは、仮想マシン上のFileMaker Pro 5.5/6（FMP）からFMSにアクセスしたときの操作が極端に遅くなること。今回、新マシン（下図のVM）と旧マシン（下図Win Server 2008）上の FMP から FileMaker Server 5.5（FMS）上の郵便番号.fp5（レコード12万件）に対しソートを実行し、この実行時間を遅速判断の1つの基準としました。

　12万件ソートの時間計測は、異なる5つのHypervisor機（Dell PowerEdge 2台、HP Proliant 1台、Lenovo X 2台）上に仮想マシンを作成し、様々なチューニングを試しながら繰り返し行いましたが、最速で20秒、最遅では2分強と、サーバ個体やNICの設定により結果が大きく異なったのには閉口しました。

　では、仮想マシン上の Remote Desktop Service に FMP を乗せ、FMSにアクセスするシナリオで、旧マシンに比べ仮想マシンが遅い場合の対処方法を小社の今回の経験からご紹介します。

※一つずつ試してください。

物理NICが Broadcom NetXtreme Gigabit Ethernet の場合、NICの詳細設定で　Virtutal Machine Queues を Disable にするとともに、Hyper-V Manager の仮想マシンの「ネットワークアダプター」で「仮想マシンキューを有効にする」のチェックを解除。
NICの詳細設定で、「TCP/UDP Checksum Offload (IPv4)」と、「TCP/UDP Checksum Offload (IPv6)」を Disable にする。
Hyper-V Manager で、（普通のネットワークアダプターではなく）レガシネットワークアダプターを構成する。
ネットでHyper-Vのチューニング情報を漁って試す（例：Performance Tuning for Hyper-V Servers）。
そもそもロジックボード設計が Hyper-V に適していない→マシンを変える

　小社の今回の経験では、上記3が有力と思います。5の状況にならないようにするには、導入前にベンダーのSEに聞いてみるか、導入実績のあるサーバを導入するか、試用機を借りて事前テストする、位でしょうか。

2.　FileMaker Server 5.5 を仮想マシン上で運用する

これについては、レガシネットワークアダプターよりも、普通のネットワークアダプタの方が有利（速い）というテスト結果です。

　同じ仮想マシンであるにもかかわらず、サーバとして利用するのと、クライアントで利用するのとで、採用すべき仮想NICの構成が異なるというのは不思議です。

（土屋）

■ FileMaker 5/6等レガシーシステム関連記事

まだまだいける FileMaker 5.5/6　― レガシーFileMaker の延命 2021 ―(21/07/24投稿)
レガシーFileMaker とOSの互換性、移行時の留意点について

IIS6 + FileMaker Web コンパニオン構成の Web サーバ機で TLS1.2 が動作するようにリバースプロキシを設定する (20/07/06投稿)
TLS1.2 非対応の IIS6 に Web ブラウザアクセス時に警告メッセージが出ないようにする

太古の FileMaker システムを延命させる！ ― 後日談FileMaker（17/09/07投稿）
下記記事のレガシー延命スキームの実施と結果について。

太古の FileMaker システムを延命させる！（17/04/25投稿）
Remote Desktop Server/FileMaker Pro 5.5 搭載の Windows Server 2008 物理マシンを P2Vし、Hyper-Vに移行することにより、レガシーシステムの延命を図る。

FileMaker 5.5/6 をモバイルで使う（16/05/25投稿）
Android/iOS に Remote Desktop Client を載せて、FileMaker Go のようなことをしてみます。

今なお輝くFileMaker 5.5/6（16/05/23投稿）
レガシーFileMaker の意外な利点。

2017-06-27

FileMaker データベース認証に oAuth を利用する

　FileMaker 16 の新機能を使用して弊社在庫管理システムテンプレート『FMEasy在庫』の機能を拡張するというテーマで、前回までに WebDirect を使用した宅配便送状の印刷と、AfterShipから配送データを取得してアプリ内で荷物追跡情報を表示する方法をご紹介してまいりました。今回はその締めくくりとして、oAuth による FileMaker データベース（以下、FileMaker DB）へのログインについてご説明します。

　一回目：FileMaker と WebDirect 16 で宅配便送状を印刷し、配送状況を追跡する
　二回目：cURL と REST API を使用し、FileMaker アプリ内で配送状況を追跡

oAuth 認証で FileMaker にログインし、出庫画面から送状発行と追跡をする

出庫画面から運送業者の送状を発行し、配送状況を追跡するまでの流れ

　oAuth は一連のデータベース操作の窓口を担う認証機能になりますが、FileMaker DB にパスワードを記憶させないという利点があります。

オープン認証（oAuth）をざっと説明

　oAuth を簡単に説明すると、外部の Web サービスに登録されているユーザ情報を使うことによって、アプリケーションに代理ログインできるしくみです。Google アカウントや Microsoft アカウントなどを使って外部サービスにログインされた方もいらっしゃると思います。

　FileMaker 16 が oAuth 対応になり、通常の FileMaker アカウントの代わりに Google、Microsoft Azure Active Directory、および Amazon アカウントを使って FileMaker データベース（以下、FileMaker DB）にログインできるようになりました。

oAuth 経由で FileMaker にログインするための事前準備

　oAuth で FileMaker DB にログインするためには、以下のものをそろえる必要があります。

FileMaker Server 16 と必要数分のアクセスライセンス
有効なドメインのサーバ証明書
クライアント ID、シークレット、テナント ID (Asure の場合)
oAuth 用ログインユーザアカウント

FileMaker で oAuth を有効にする方法

　oAuth 経由で FileMaker にログインするための具体的な手順を以下に示します。

ここでは、Google アカウントを例に進めていくことにします。

　作業の手順は FileMaker 公式にまとめられていますので、以下もご参照ください。
　オープン認証 (OAuth) 資格情報を使用したソリューションへのアクセス

FileMaker Server にサーバ証明書をインポートします。
FileMaker Server Admin Console にログインし、データベースサーバ→セキュリティの順にすすみ、「データベース接続に SSL を使用する」にチェックをつけて“証明書のインポート...” ボタンをクリックします。

SSL を有効にし、証明書のインポートを選択する

　証明書のインポートダイアログが表示されますので、署名入りの証明書ファイル、プライベートキーファイル、中間証明書ファイルを指定してインポートします。

カスタム証明書インポートのダイアログ
FileMaker Server を再起動します。
http://console.developers.google.com/ にログインします。
認証情報→認証情報を作成の順にすすみ、「oAuth クライアント ID」を選択します。

oAuth クライアント ID を登録
oAuth 同意画面を選択し、メールアドレスとサービス名を入力して保存します。

oAuth 同意画面を登録
アプリケーションの種類の選択ページでは、「ウェブアプリケーション」を選択し、任意の名前を指定してから、リダイレクト先を指定します。

oAuth 認証をウェブアプリケーションにし、そのリダイレクト先を指定する

リダイレクト先は https://ドメイン名/oauth/redirect になるように指定します。
無事 oAuth クライアント ID が作成されると、以下のようなダイアログが表示されますので、クライアント ID とクライアントシークレットをメモしておいてください。

oAuth クライアントのクライアント ID とクライアントシークレットを取得する
再び FileMaker Server Admin Console にログインします。データベースサーバ→セキュリティの順にすすみ、クライアント認証を「FileMaker と外部サーバーアカウント」に変更して設定を保存します。

クライアント認証を「FileMakerと外部サーバーアカウント」に変更する
外部サーバーアカウントとして Google の歯車アイコンをクリックすると、Google の設定ダイアログが表示されますので、手順 7. でメモしておいた Google クライアント ID と Google クライアントシークレットを入力し、“保存”ボタンをクリックします。

Google クライアント ID と Google クライアントシークレットを入力
FileMaker Server を再起動し、手順 11. の Google アカウントのスライダーを有効にします。

　これで FileMaker Server で oAuth が使えるようになりました。

補足事項：

サーバ証明書をインポートした直後は、FileMaker Server を再起動しても FileMaker Server が証明書を認識しない場合があります。その場合は、いったんサーバ機を再起動すると認識されることがあります。
サーバ証明書のインポートに失敗した場合は、FileMaker Server のディレクトリでコンソールウィンドウを開き、fmsadmin certificate delete コマンドを実行すると、カスタム証明書を削除することができます。削除後はいったん FileMaker Server を再起動してから、証明書のインポートをやりなおしてみてください。

FileMaker データベースファイルへのユーザアカウントの登録

　FileMaker Server 側の oAuth 認証受付の準備が終わったら、データベースファイルにログインユーザアカウントを登録します。

FileMaker Pro から管理者権限でデータベースファイルを開き、FileMaker のメニューより「管理」→「セキュリティ」の順に進みます。
アカウントの一覧が表示されますので、認証方法を「Google」にし、そして「ユーザ名」にはGoogleにログインするためのメールアドレスをフルで指定します。

アカウント管理画面に oAuth ログイン用のユーザアカウントを登録する
同じ要領で、クライアント数分のアカウントを登録します。

補足事項：

分離モデルを採用している FileMaker データベースシステムの場合は、関連するすべてのファイルに oAuth 用のアカウントを登録する必要があります。

oAuth による FileMaker データベースのログイン

　oAuth による FileMaker ログインの設定が終わったら、実際にログインして動作を確認します。

FileMaker Pro16 によるログイン

　FileMaker Server 16 で公開されているデータベースファイルに FileMaker Pro 16 クライアントからアクセスすると、以下のようなダイアログが表示されます。

oAuth 対応のFileMaker Pro 16 ログイン画面

ここで、Google ボタンをクリックすると、以下のようなアカウント選択ページが表示されますので、適切なアカウントを選択し、パスワードを入力してログインします。

ログインする Google アカウントを選択

上図は、Web ブラウザに Google アカウントが記録されている場合のページですが、Web ブラウザにアカウントが記録されていなければ Google ログイン用のメールアドレスを入力するよう促されますので、正しいメールアドレスを入力します。

　Google アカウントのログインに成功すると、以下のようなダイアログが表示されますので、“許可”をクリックします。

プログラムの実行許可

　すると FileMakerアプリの画面に戻ります。後の操作は FileMaker のユーザ権限にしたがって通常通りに行えます。

oAuth による FileMaker ログイン直後の Main Menu 画面(FileMaker)

oAuth によるFileMaker ログイン直後の FMEasy在庫 Main Menu 画面

WebDirect によるログイン

　WebDirect 用の公開リンクにアクセスし、開きたいデータベースファイルをクリックすると、以下のようなログインページが表示されます。

WebDirect 用の oAuth 対応サインインページ

ログインする Google アカウントを選択

　
　Google アカウントのログインに成功すると、WebDirect で FileMaker DBが開きます。

oAuth による FileMaker ログイン直後の Main Menu 画面(WebDirect)

oAuth による WebDirect ログイン直後の FMEasy在庫 Main Menu 画面

懸案事項

　oAuth は事前設定さえ済ませてしまえば、あとはログインを許可するアカウントを FileMaker DBに登録するだけで使えるようになりますが、運用にあたっては以下のような問題が発生する可能性がありますので、ご留意ください。

ログインに成功すると、FileMaker を終了しても、oAuth で管理される外部 Web サービスのセッションが残る
これは他の Web サービスのセッション管理機能に依存しますが、Google の場合 FileMaker を終了させても、二回目以降に FileMaker DB にログインしようとすると、パスワードの入力を求めてこず、そのままログインできてしまいます。
Web ブラウザにログインパスワードが保存されていると、第三者に勝手にログインされる恐れがある
個人の専用パソコンからのアクセスなら、パスワード入力の手間が省けて便利ですが、複数のユーザで一つのパソコンを共有利用している場合は、勝手にログインされてしまう可能性があります。

　各自パスワード管理をしっかりやってね、で解決すればよいのですが、手軽さゆえ思わぬトラブルにつながりそうな機能なので、oAuth ログインを許可するアカウントのユーザ権限は入力・照会レベルにとどめるような工夫は最低限必要かと思います。

　oAuth の危険性を指摘する記事もネットで見つかりますので、日ごろから目を通しておくとよいですね。

　参考記事：第147回　便利と危険は裏返し　〜知っておきたい、OAuthの仕組み〜（TDK Techno Magazine）

　土屋企画では FileMaker システムの受託開発およびコンサルティングを請けたまわっております。お問い合わせはこちらよりお願い致します。

　その他の在庫関連記事を読む

（亀）

2017-06-26

cURL と REST API を使用し、FileMaker アプリ内で配送状況を追跡

　前回は在庫管理テンプレート『FMEasy在庫』をカスタマイズし、宅配便の送状を印刷・登録するところまでをご説明しました。

　前回の記事： FileMaker と WebDirect 16 で宅配便送状を印刷し、配送状況を追跡する
　参考：FMEasy在庫 IWP/WD R1.5

出庫画面から運送業者の送状を発行し、配送状況を追跡するまでの流れ

　本稿では、出荷後の配送状況の追跡機能を実装する方法（上図の7.と8.）について説明していきます。
　機能の実装に入るまえに、FileMaker から出荷物の配送状況を取得するしくみについて触れます。

世界402社と日本3社の配送業者の追跡データAPIを提供する AfterShip

　FileMaker 単体では宅配便の配送状況の情報を取得することはできません。このため、各宅配業者が提供する追跡サービスを使用することになります。

　これまでは、データ受信の窓口となる API サービスを利用するためには宅配業者別に手続きが必要になり、API 接続手順の把握とシステムへの追跡機能の実装までに大変な手間と時間がかかってしまったのですが、AfterShip という荷物追跡サービスは世界 402 社の配送業者の追跡データ API を提供しており、その中に日本のヤマト運輸、佐川急便、日本郵便の 3 社も含まれています。

　AfterShip が対応している日本の宅配便会社（Japan を選択）

　つまり、AfterShip の API を利用すれば、これら 3 社の配送状況の追跡をまとめて処理でき、FileMaker の送状発行機能と連携させることによって、送状の印刷から荷物追跡までがトータルに行えるようになります。

AfterShip の利用料金について

　2017年6月26日現在、AfterShip は 1月あたり 100 個までの出荷物の追跡が無料となっています（Basic プラン）。
　100 個を超える荷物を追跡するには、その個数に応じた料金が適用される Premium プラン、10万個を超える場合は個別対応の Enterprise プランという料金が適用されます。

　価格プランはこちらを参照してください。
　https://www.aftership.com/pricing

　たとえば、一月あたり 10,000 個なら $173/月、50,000 個なら $573/月となりますので、出荷量に応じた追跡計画を立てることができます。

7. AfterShip に配送状況を問い合わせる

　AfterShip の API サービスを利用するまえに、AfterShip へのユーザ登録が必要になります。

　AfterShip ユーザ登録・ログインページ
　https://secure.aftership.com/signup/

　google アカウントをお持ちの方は、google アカウントでログインするだけで自動的に AfterShip に登録されます。

　FileMaker から AfterShip API を利用できるようにするには、さらに API Key の取得と配送業者の登録が必要になります。

AfterShip API Key を取得する
AfterShip へのユーザ登録が終わったら、設定ページから API の順に進み、API Key を取得します。　
　通常は登録完了時に自動的にデフォルトの API Key が付与されますのでそれを使えばよいですが、必要に応じて Key を追加生成することもできます。

AfterShip API key の取得
追跡対象の配送業者（couriers）を登録する
出荷物の追跡を行いたい配送業者を登録します。設定ページから couriers の順に進み、inactive 入力ボックスに japan と入力すると、日本の配送業者が表示されますので、その中から必要な業者を選びます。

　以下の図は、ヤマト運輸の選択まで終わったところです。

配送業者（couriers）の登録ページでヤマト運輸の登録が終わったところ

　それでは、いよいよ FileMaker からAfterShip を呼び出すための設定をします。
　AfterShip API は REST 形式になっており、配送状況の追跡を行うためには基本的に以下の情報が必要となります。

AfterShip API への URI（https://api.aftership.com/v4/）
配送会社識別コード（slug）
送状番号(tracking_number)

　配送会社識別コードと送り状番号は FileMaker のユーザインタフェースから登録できるようにしておき、AfterShip API からの応答データを登録するためのフィールド群も用意します。

　下図の赤で囲んだ部分をご覧ください。ポータルの 2 段目が AfterShip から取得する追跡データを保存するためのフィールド群です。荷物（送状）の追跡を行う場合は、当然[送状No]も必要になります。

　AfterShip API の公式ドキュメントはこちらです。

　AfterShip API Documentation
　https://www.aftership.com/docs/api/4/overview

　それでは、このドキュメントに従って、FileMaker から AfterShip API に接続してみましょう。

　AfterShip への送状番号の登録

　解説ページ：https://www.aftership.com/docs/api/4/trackings/post-trackings

　AfterShip 経由で荷物の配送状況を追跡するには、先に送状番号を AfterShip に登録しておく必要があります。

　登録用の URI は https://api.aftership.com/v4/trackings/ になります。
　この URI に送状情報を POST メソッドで送信すれば、AfterShip に登録されます。

　php で記述した場合、たとえばこのようになります。

PHP


<?php

    //build header 
    $header = array( 

        'Content-Type: application/json',
        'aftership-api-key: cfa68bc1-5b9b-4ba2-b3c8-XXXXXXXXXX'

    ); 


    //build invoice data
    $data = Array(
        'tracking' => Array(
            'slug' => 'taqbin-jp',
                'tracking_number' => '44361185XXXX',
                'title' => 'YAMATO POST TEST'
        )
    );  

 
    //post data using curl
    $curl = curl_init();
    curl_setopt( $curl, CURLOPT_URL, 'https://api.aftership.com/v4/trackings' );
    curl_setopt( $curl, CURLOPT_CUSTOMREQUEST, 'POST' );
    curl_setopt( $curl, CURLOPT_HTTPHEADER, $header ); 
    curl_setopt( $curl, CURLOPT_POSTFIELDS, json_encode( $data ));
    curl_setopt( $curl, CURLOPT_SSL_VERIFYPEER, true );
    curl_setopt( $curl, CURLOPT_RETURNTRANSFER, true );
    $result = curl_exec( $curl );
    $json = json_decode( $result );
    curl_close( $curl ); 

?>

　$header の中に json データ送信を宣言し、 aftership-api-key を指定します。
　$data の中に指定している slug がヤマト運輸を示す taqbin-jp、 tracking_number が送状番号、title が AfterShip の中で送状の識別を用意にする任意のタイトルになります。
　送信結果は最終的に $json 変数に格納されます。

　これを FileMaker の「URL から挿入」ステップで記述すると、たとえばこのようになります。

FileMaker


変数を設定 [ $data; 値:
JSONSetElement ( "" ; 
        [ "tracking.tracking_number" ; "44361185XXXX" ; JSONString ];
        [ "tracking.slug" ; "taqbin-jp" ; JSONString ]; 
        [ "tracking.title" ; "YAMATO POST TEST" ; JSONString ] 
    )
 ]
URL から挿入 [ $json; "https://api.aftership.com/v4/trackings"; 
    cURL オプション: "-H \"Content-type: application/json\" " & 
        "-H \"aftership-api-key: cfa68bc1-5b9b-4ba2-b3c8-XXXXXXXXXXX\" " & 
        "-d " & $data ] 
    [ ダイアログなし; SSL 証明書の検証 ]

　php に比べると指定方法に多少コツがいりますが、かなりシンプルになりますね。

　$data の中に送状情報を組み立てておき、これを「URL から挿入」ステップの cURL オプションの -d オプションの中に指定することによって送信します。

　cURL オプション:
　"-H \"Content-type: application/json\" --- ヘッダオプション。json 形式のデータ送信を宣言
　"-H \"aftership-api-key: cfa68bc1-5b9b-4ba2-b3c8-XXXXXXXXXXX\" --- ヘッダオプション。aftership-api-key を指定
　"-d " & $data --- データオプション。$data に格納されているデータを送信

　送信結果は $json 変数に格納されますので、その中から必要項目を取り出せばよいことになります。

AfterShip API から戻される結果

　AfterShip API の戻り値は json 形式になります。前述の例では $json 変数に戻ってくるので、これを解析して利用します。
　データは一行で返りますので、これを FileMaker Pro 16 の JSONFormatElements 関数を通すと見やすいフォーマットに整形されますので、戻りデータを確認する際に有用です。

　JSONFormatElements( $json ) の結果はたとば以下のようになります。

JSON


{
 "data" : 
 {
  "tracking" : 
  {
   "active" : true,
   "android" : [],
   "checkpoints" : [],
   "created_at" : "2017-06-24T13:08:42+00:00",
   "custom_fields" : null,
   "customer_name" : null,
   "delivery_time" : 0,
   "destination_country_iso3" : null,
   "emails" : [],
   "expected_delivery" : null,
   "id" : "594e645ab6ee5fcf0b7XXXXX",
   "ios" : [],
   "last_updated_at" : "2017-06-24T13:08:42+00:00",
   "note" : null,
   "order_id" : null,
   "order_id_path" : null,
   "origin_country_iso3" : null,
   "shipment_delivery_date" : null,
   "shipment_package_count" : 0,
   "shipment_pickup_date" : null,
   "shipment_type" : null,
   "shipment_weight" : null,
   "shipment_weight_unit" : null,
   "signed_by" : null,
   "slug" : "taqbin-jp",
   "smses" : [],
   "source" : "api",
   "tag" : "Pending",
   "title" : "YAMATO POST TEST",
   "tracked_count" : 0,
   "tracking_account_number" : null,
   "tracking_destination_country" : null,
   "tracking_key" : null,
   "tracking_number" : "44361185XXXX",
   "tracking_postal_code" : null,
   "tracking_ship_date" : null,
   "unique_token" : "deprecated",
   "updated_at" : "2017-06-24T13:08:42+00:00"
  }
 },
 "meta" : 
 {
  "code" : 201
 }
}

　ここで、"meta" :{"code" : 201} が登録成功を示すシステムコードです。このコードが返れば AfterShip のブラウザ管理画面の追跡リスト上にこの送状データが表示されるようになります。
　また、このコードを拾って FileMaker テーブルのフィールド（下図の[ステータスコード]）に登録したい場合は、以下のように関数を指定します。

　JSONGetElement ( $json ; "meta.code" )

　同じ要領でタイトルを下図の[aftershipタイトル]に登録する場合は、関数を以下のように指定します。

　JSONGetElement ( $json ; "tracking.title" )

　AfterShip への登録日時を下図の[ステータス]に登録するには、JSONGetElement ( $json ; "date.tracking.created_at" )と指定します。

AfterShip に送状情報を登録した直後の様子

　“登録”ボタンにより AfterShip に送状を登録した後に、ブラウザでAfterShipの送状管理画面を見ると、下図のようになっています。

AfterShip に登録された送状の一覧

8. 配送状況の問い合わせ結果を FileMaker に登録する

　AfterShip に配送状況を照会する

　解説ページ：https://www.aftership.com/docs/api/4/trackings/get-trackings-slug-tracking_number

　AfterShip に荷物を登録後、配送状況を追跡するための URI は https://api.aftership.com/v4/trackings/配送業者コード(slug)/送状番号(tracking_number) になります。
　この URI に？？？送状情報を GET メソッドで送信すれば、AfterShip から配送状況が JSON 形式のデータで戻されます。

　AfterShip への配送状況の問い合わせを FileMaker の「URL から挿入」ステップで記述すると、たとえばこのようになります。

FileMaker


URL から挿入 [ $json; "https://api.aftership.com/v4/trackings/" & 
    "taqbin-jp" & "/" & 
    "44361185XXXX"; 
cURL オプション: "-H \"Content-Type : application/json\" " & 
　　　　"-H \"aftership-api-key: cfa68bc1-5b9b-4ba2-b3c8-XXXXXXXXXXX\" & "\" " ] 
[ ダイアログなし; SSL 証明書の検証 ]

　登録のときより照会の方が単純ですね。
　これによって $json 変数に配送状況の照会データが戻ります。
　照会に成功すると、 "meta" :{"code" : 200} が返ります。
　オプション解説、およびデータの読み出し方法の基本については、前述の登録方法の項をご覧ください。

　なお、最終の配送状況のみを戻したい場合は、 URI を https://api.aftership.com/v4/last_checkpoint/配送業者コード(slug)/送状番号(tracking_number) にすればよいです。

　解説ページ：https://www.aftership.com/docs/api/4/last_checkpoint/get-last_checkpoint-slug-tracking_number

　下図は各送状の“照会”ボタンを実行し、［ステータス］（一般ユーザ向けに配送状況を表示）と[ステータスコード]（システム管理者向けにシステムコードを表示）の更新が完了したときの画面です。

送状情報を AfterShip に問い合わせたときの様子

　上図では最終ステータスのみを記録するように作成していますが、機会があれば［追跡履歴］の取り出し方も説明できればと思います。

外部サービスを使うデメリットについて

　FileMaker 単体でできないことは外部サービスの力を借りることになりますが、導入時は魅力的に見えたサービスであっても、継続運用していくうちに様々な問題に直面することがあります。

そこで最後に外部サービスを利用する際の注意点をいくつか挙げておきます。
　

バージョンアップに伴い、従来の呼び出し方法では動作しなくなる
FileMaker と外部サービスとの連携が取れなくなる恐れがあります。
外部サービスを導入する場合は、こまめなチューニングも考慮する必要があります。
無料サービスが有料化される
そのサービスなしでは業務が回らない場合に、予期せぬコスト増大を招く恐れがあります。
良心的に見えた料金が値上がりする
サービス提供側が料金を値上げするのはよくあることです。その場合、上記と同様にコスト増大が発生します。
社外秘のデータが外部に把握される
サービスの内容にもよりますが、たとえばアンケート収集・解析サービスや、SNSサービス、翻訳サービスなど、社内用のデータを外部サービスと連携させて利用する必要がある場合、機密情報を外部サービスに流さないように注意を払うことはもちろんのこと、サービス提供会社の安全性やセキュリティ対策なども調査する必要があります。
終了する
有料、無料にかかわらず、サービス提供側の事情でサービスが終了すると、そのサービスがシステムにとって重要なポジションを占める場合には、代替サービスの選定やシステム修正等の手間が増えることになります。

　FileMaker 16 の機能追加によって、外部 Web サービスとの親和性が向上しましたが、本格的にサービスを導入をするには、上記のような問題を視野に入れたうえでプロジェクトを設ける必要がありますので、発注側、受注側双方の理解が重要かと思います。

（亀）

　土屋企画では FileMaker システムの受託開発およびコンサルティングを請けたまわっております。お問い合わせはこちらよりお願い致します。

　その他の在庫関連記事を読む

登録: 投稿 (Atom)

メニューバー

2018-08-09

目的

条件

結果

考察

目的

条件

考察

目的

条件

結果

考察

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

使用デバイス

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

結果

参考サイト：

IPS関連のBlog記事

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

2018-05-24

Windows Server に PostgreSQL 10 インストール時に 「Error with Configuration or permission 」という警告が出る場合の対処方法

PostgreSQL 10 インストール失敗の対応方法

不具合の原因

2018-04-10

IPS関連のBlog記事

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

2017-12-30

多数移動体位置監視モデル

通信端末について

移動体通信会社（MVNO）

システム構成とプロトタイプ開発

ハイブリッドアプリとアプリケーションサーバの仕様と処理分担

プロトタイプのテスト

SORACOM Global について

2017-11-14

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

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

2017-09-07

1. FileMaker Pro 5.5/6を仮想マシン上で運用する

2. FileMaker Server 5.5 を仮想マシン上で運用する

2017-06-27

オープン認証 （oAuth） をざっと説明

oAuth 経由で FileMaker にログインするための事前準備

FileMaker で oAuth を有効にする方法

FileMaker データベースファイルへのユーザアカウントの登録

oAuth による FileMaker データベースのログイン

FileMaker Pro16 によるログイン

WebDirect によるログイン

懸案事項

2017-06-26

世界402社と日本3社の配送業者の追跡データAPIを提供する AfterShip

AfterShip の利用料金について

7. AfterShip に配送状況を問い合わせる

AfterShip API Key を取得する

追跡対象の配送業者（couriers）を登録する

AfterShip への送状番号の登録

AfterShip API から戻される結果

8. 配送状況の問い合わせ結果を FileMaker に登録する

AfterShip に配送状況を照会する

外部サービスを使うデメリットについて

Windows Server に PostgreSQL 10 インストール時に「Error with Configuration or permission 」という警告が出る場合の対処方法

2.　FileMaker Server 5.5 を仮想マシン上で運用する

オープン認証（oAuth）をざっと説明

　AfterShip への送状番号の登録

　AfterShip に配送状況を照会する