2021-07-24

まだまだいける FileMaker 5.5/6 ― レガシーFileMaker の延命 2021 ―

 FileMaker 5.5/6 の発売は今から約20年前ですが、巷ではまだまだ使用している会社も多いです。 今回は レガシーFileMaker のサーバとクライアントのOSの互換性に関して、当社の運用実績、検証、推測を基にレポートします。また、レガシーの修正や改変の際に必要となる分析方法についても記します。

※Windows 11 は 64bit マシン専用OSですが、通常は Windows 32bit アプリケーション も運用可能です。 アプリケーションによっては障害が発生する可能性がありますが、32bit アプリである FileMaker Pro 5.5/6 も Windows 11 にインストールし、起動することができます。 2021年10月現在、トラブル無く運用できています。 今後、運用時間を延ばし、本稿にて状況をレポートする予定です。


FileMaker の最強3トップ

注:
  • レガシーFileMakerのOSとの互換性/延命に関するご意見等は、コメント欄にご投稿ください。
  • 本稿に基づき読者がシステムを構築された場合に問題や障害等が発生しても、当社では責任を負いません

FileMaker Server 5.5とWindows OSとの互換性 

 下表はFileMaker Server 5.5(以下、FMS)と Windows OS との互換性を示します。

Windows  OS 互換性 備考
2000 Server FileMaker社による動作保証
2003  当社等の運用実績に基づく[1]
2008 当社等の運用実績に基づく[1]
2012 当社等の運用実績に基づく[2]
2016 当社検証に基づく、非推奨[3]
2019 ? 未検証[4]
     
2000 Pro FileMaker社による動作保証
XP ? 未検証[5]
7 ? 未検証[5]
10 × 当社検証に基づく、非推奨[6]
[1]:「当社他の運用実績」は、当社及び当社顧客の運用実績有
[2]: 運用可。但、FMS管理コンソールでクラッシュするケースあり、以下の「仮想マシン上で FMSを運用する場合」参照
[3]: DB公開はできるがFMS管理コンソールでクラッシュする、非推奨
[4]: 2019はWindows10系である為、公開はできるがFMS管理コンソールでクラッシュすると推定、非推奨
[5]: System7はWindows 2000 Pro(公式サポートOS)に近いため運用できる可能性有、検証の価値有
[6]: FMS管理コンソールでDBを公開できる時とできない時があり非常に不安定、非推奨

FileMaker Pro 5.5/6 とWindows OSの互換性

 下表はFileMaker Pro 5.5/6(以下、FMP)と Windows OS との互換性を示します。
表中、サーバOSが含まれていますが、これはリモートデスクトップサービスを使用し、マルチユーザライセンスのFMPを複数ユーザで使用することを想定しています。

Windows  OS 互換性 備考
2000 Pro/Server FileMaker社による動作保証
2003  当社等の運用実績に基づく[1]
2008 当社等の運用実績に基づく[1]
2012 当社等の運用実績に基づく[1]
2016 当社等の運用実績に基づく[1]
2019 未検証[2]
     
XP FileMaker社による動作保証
7 当社等の運用実績に基づく[1]
10 当社等の運用実績に基づく[1]
11 2021年10月現在テスト中。経過は順調[3]
[1]:「当社他の運用実績」は、当社及び当社顧客の運用実績有
[2]: 2019はWindows10系である為、運用可能と推定
[3]: 2021年10月現在Hyper-VにWindows11を搭載しテスト中。適時本ページで経過をレポート予定。

新設するサーバ機とOSとの互換性(仮想マシン不使用)

 サーバ機の老朽化によるマシン本体のリプレースについて考えます。この時、仮想マシンを使用せずに、新サーバ(物理マシン)に Windows 2000/2003/2008/2012 をインストールし、このOS上で FMS を運用しようとする場合、物理マシンが各OSをサポートしているか否かはチェックポイントとなります。経験上、メーカーが公式対応していないOSであっても動作する可能性は高いですが、メーカーが公式対応を謳っているマシンであれば、それに越したことはありません。

Dellサーバ機のOS互換性

HPサーバ機のサーバOS互換性

仮想マシン上で FMSを運用する場合

次に仮想サーバ上での FMSの運用について考えます。この方法では仮想マシンにWindows 2000/2003/2008/2012 をインストールして、FMS を運用します。
 既に仮想環境を構築済みであれば、マシン調達に伴う金銭的コストを負わなくても済むので、担当者の心理的負担は少ないです(経験者談)。逆にFMSだけのために仮想環境を新たに導入するとなると、コスト大の上、担当の心理的負担も大となります(同談)。

 注意点が一つあります。当方で遭遇した現象ですが、Dell PowerEdge T105 のハイパーバイザ上の仮想マシン(Windows Server 2012R2 )では、 FMS5.5 が問題なく動作していましたが、PowerEdge R330 のハイパーバイザ上の仮想マシン(Windows Server 2012R2 )に FMS5.5 を新規インストールした後にFMS の コンソールで「ファイルメーカー Server」を右クリックして「プロパティ」を選択するとコンソールがクラッシュする、ということがありました。 この時、正常稼働している PowerEdge T105 上 の仮想ディスク(VHD)を丸ごと PowerEdge R330 にコピーして仮想マシンを再構成したところ、コンソールで「プロパティ」を選択することができました。
 このように、一見同じに見えるシステム環境であっれも、FMSで障害が発生することがある、と言う事です。
 
 当社ではFileMakerレガシーの延命を多くうけたまわっており、現在までほぼ成功裡に終わっていますが、リスクがあることをユーザに十分理解頂き、業務を進行することがやはり大切です。
 もっとも、最新のテクノロジーでシステムを構築する!、と言っても、既存システムとの互換性、開発失敗リスク、最新テクノロジー故の不安定性・未成熟性といったリスクもあります。また、ベンダーが勝手に契約条件を変更する近年のサブスクリプションというビジネスモデルも大きなリスクです。

 5G、AI、機械学習、IoT/M2M、DXを行わない企業に未来はない!などと、漠然としたIT用語や根拠不明の言説が巷に溢れる中、現行仕様で満足している、或いは現行仕様を修正・拡張しながら利用できれば十分というシステムも普通にあるわけで、であればレガシーシステムの延命は十分考慮に値すると思います。


Windows Server の Windows Update 

 Windows update を行わなければ FileMaker Server 5.5(FMS) が動作しないということはありませんが、Windows 2008/2012 などの古いOSを運用する際に重要なことなので、本項にて触れておきます。

 通常、新たにサーバ機を購入したり、サーバOSをインストールした際は、Windows update を行い、OS を最新の状態にします。これは以下の理由によります。
  1. セキュリティ上の要請
  2. 運用開始後の Update のリスクを低減する
    運用開始後に Windows update を実施すると、何らかの障害が発生し、運用中のソフトウェアが動作しなくなる可能性があります。できるだけ導入・テストの段階で利用可能な全ての update を当て、運用後のダウンタイムを減らしましょう。
  3. Windows Server がある程度最新の状態でないと動作しないプログラムがある
    ある種のアプリケーションをインストールする際、一定のバージョン以上の Internet Explorer や .NET Framework を要求され、インストールを実行できない、ということはままあります。この一定のバージョンに辿り着くまで、何回か Windows update を行う必要があることがあります。導入時に最新のUpdateを当てておけば、運用後にこれらの作業を低減することができます。
  4. Windows Update 自体が動作しなくなることがある
    後述のように Windows Update エージェントが古いと Update 自体ができないことがあります。

Windows update ができない時 

 FileMaker Server 5.5 と互換性の高い Windows Server 2008/2012 ですが、これらのOS のインストール直後に Windows update を実行すると、 0x80072efe というエラーが発生して、Windows Update が完了しないことがあります。
 このエラーは Windows Update エージェント自体に問題あり、Windows Update エージェントのアップデートプログラムを単独でダウンロードし、これを実行することにより解決できます。

 ※ご利用の Windows Server のバージョンに適合したものをダウンロード後、インストールしてください。

 この他にも、いくつかのアップデートを実行できないこともあります。その場合は Windows Update の順番を変えてみたり、個別にアップデートプログラムをダウンロードしたりして対応する必要が出てきます。

 以上、運用開始後のダウンタイムを低減するために、導入段階で Windows Update をできるだけ進め、OSを最新の状態にしておきましょう。

Windows Server のライフサイクル

 参考までに、Windows Server のライフサイクルの表(2021/07/26時点)を挙げておきます。
Windows  OS サポート終了日 延長サポート終了日
Windows Server 2003 2010/07/13 2015/07/14
Windows Server 2003R2 2010/07/13 2015/07/14
Windows Server 2008 2015/01/13 2020/01/14
Windows Server 2008 R2 2015/01/13 2020/01/14
Windows Server 2012 2018/10/09 2023/10/10
Windows Server 2012 R2 2018/10/09 2023/10/10
Windows Server 2016 2022/01/11 2027/01/12
Windows Server 2019 2024/01/09 2029/01/09

実行速度とテストについて

 物理マシン或いは仮想マシンを問わず、構築した新環境に於ける実行速度が旧環境のそれに比べて明らかに遅い場合、問題となります。 旧環境から新環境への移行業務の早い段階で、必要十分な実行速度が得られているかをユーザに判断してもらうべきです。 業務終了間際に実行速度が遅すぎると判明すると、行った作業が全て無駄になる可能性があります。

 当社では実行速度の可否を判断する際、約12万件の郵便番号情報が入った郵便番号.fp5 のファイルをFMSで公開し、FMPからアクセスして住所フィールド(都道府県+市区町村+町域を1つに結合したフィールド)のソートを行います。 この12万レコードのソートが30~40秒程度で終了する、というのを一応の合格基準としています。
注:
これは未ソートの状態で新たににソートした場合の基準です。一旦ソートされた状態で再度ソートすると、ソート時間が30~40%改善するとがあります。このため、ソートテストは常にソートされていない状態で実行してください。

 ユーザは実行速度には敏感ですので、旧環境と新環境で郵便番号をソートのデモを行うのも良い考えだと思います。

 当方の経験上、コア数やメモリも増やしても、実行速度はほとんど改善されません。ただ、ネットワーク(NIC)の設定を変更することにより、劇的に改善することがあります。これについては、こちらを参照してください。

レガシーFileMaker の分析

 当社では第三者が開発したレガシーFileMakerの保守・開発を引き受けていますが、そのシステムを拝見するとデータベースの正規化が無視されていたり、同種のスクリプトを延々と繰り返していたり(コードの再利用という考えがない)、逆にスクリプトが意味不明に細かく分割されていたり、セキュリティが考慮されていなかったりと、掟破りのシステムを目にすることが少なくありません。

 掟破りシステムに障害があると、当社担当が分析・修正するとなるとなります。熟練開発者が書いたスクリプトでも、その開発者の支援無しに第三者がデバッグするのは元々困難な作業です。 これが非熟練者により開発されたものとなると、通常の十倍からそれ以上の工数を要する大変な作業となります。 このような状況では、スクラッチ開発(一から再開発)お勧めしたいのですが、膨れ上がった掟破りシステムをスクラッチ開発するには、多くの時間と費用を要するため、当社担当がデバッグすることになります。

 さて、このような悲惨な状況下での頼みの綱がデバッガや分析ツールですが、旧FileMaker にも FileMaker Developer 5.5/6 (以下、Developer)という製品があり、これによりデバッグや分析を行うことができます。
 Developerを使うと、下図のようなデータベースデザインレポート(実体は FileMakerのファイル)を作成することができます。 このレポートはシステムの開発量(フィールド、レイアウト、スクリプト等の数)を知るのに有用です。



 一方、検索機能が不十分、というか無いに等しいので、保守や障害対応で特定のオブジェクトの検索を行うには、データベースデザインレポートは不適です。
 例えば、システムの改変時にフィールドAに対して何らかの変更を加える場合、そのフィールドが影響を及ぼすオブジェクト(他のフィールド、スクリプト、レイアウト、値一覧、リレーション)が無いかをリストアップし、それぞれ検討を行い、悪影響があると判断される場合には対応が必要になります。この時、上記のデータベースデザインレポートには、フィールドAを指定して、関連するオブジェクトを抽出する機能がありません。
 この種の検索機能が無いと膨大な作業を人力で行う事になりますが、これは実務上ほぼ不可能となります。このため当社ではオブジェクト検索を行う以下のサブシステムを用意しています。
 

 図の「TPC Database Analyzer」は FileMaker 5.5/6用データベース分析ツールです。[検索条件]に「売上日」と入力して検索を実行すると、[売上日]を含むオブジェクトがすべて検索されます。その検索結果が下図です。


 画面左を見るとレコード数が約3万1千ありますが、これがこのシステムを構成するオブジェクトの数です。該当件数が299となっていますが、これが[売上日]が関連するオブジェクトの数です。約3万1千あるオブジェクトから人力で[売上日]を含むオブジェクトをしらみつぶしに調べるのは、実務上ほぼ不可能ですが、299件であれば一つ一つチェックしていければ、時間はかかると思いますが、熟練の開発者であれば必要な修正を加えることが可能です。

 このような分析ツールは障害や部分改変を行う際に限らず、新システムのスクラッチ開発時に旧システムを分析する際にも非常に有用なツールとなります。
(本項は21/10/14に加筆)
 
(NuckyT)




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

正月休み明け、仮想マシン上の FileMaker Server 5.5 バックアップが失敗していた(22/01/25投稿)
仮想マシンの外部ディスクでI/Oエラーが出た際の復旧方法

まだまだいける 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 の意外な利点。

2021-05-28

FileMaker用IPSアプリケーション・テンプレート ― QuickIPS ―


お知らせ

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

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

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

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


IPSとは

  小社では屋内測位システム(TPC_IPS)の開発を行っています。 IPSとは一言で言い表すと屋内用GPSであり、屋内に存在する人やモノの位置を把握するシステムです。屋内や地下では、GPS等の衛星技術では位置測位が不能であったり、十分な測位精度を出せなかったりするため、屋内で位置測位をおこなうシステムがIPS(Indoor Positioning System)であり、IoT(Internet of Things)技術の1つでもあります。

  図は倉庫におけるIPSのイメージで、ビーコンやタグと呼ばれる発信機を人やモノに取り付け、ビーコンが発する信号() を受信端末 で読み取り()、この信号情報をコンピュータで解析することにより各ビーコンの位置を測位します。この測位情報はネットワークを介して社内あるいは社外のユーザが照会することができます。 下図のように多くのモノを管理するIPSは、Asset Tracking システム(資産管理システム)と呼ばれることもあります。

【IPS/Asset Tracking システムのイメージ】

FileMaker によるIPS用ユーザアプリケーション

 下図はIPSのシステム構成例です。この例では、IPSが位置測位ユーザアプリケーションの2つのシステムに分かれています。位置測位は文字通り、各ビーコンの座標を算出します。 小社製品・TPC_IPS では2021年5月現在、BLE4のビーコンを使用して測位を行っていますが、 最近では AirTag で採用された UWB が注目されています。今後は単なる忘れ物タグにとどまらない IPS/Asset Tracking用のUWB製品が市場に現れるものと期待されます。
注:
 UWB IPS製品には UbisenseZebra といったものが以前からありますが非常に高価なため、導入は一部の大企業等に留まっていました。AirTag や SmartTag の出現は、低価格UWB IPS の普及に貢献するかもしれません。

TPC_IPSの位置測位については過去に記事(末尾のリンク参照)にしていますので、本稿では FileMaker を使用したユーザアプリケーション・テンプレート ― QuickIPS― の概要をご紹介します。

注:
QuickIPS は TPC_IPS にバンドルされますが、単体として2022年春にリリース予定です。

※ QuickIPS の仕様・予定等は、予告無く変更されることがあります。

【IPS構成図】
注:
上図の構成例ではビーコン/タグを物品に取り付け、センサーを経由してサーバで位置測位を行いますが、これはAsset Tracking (資産管理)等で見られる方式です。一方、携帯電話端末等にアプリケーションをインストールし、ビーコン/タグを屋内の特定の場所に固定、端末のアプリで端末ユーザの測位計算を行う方式もあります。こちらはよりGPS的なIPSとなります。

代表的なユーザアプリケーション

 上図のように各ビーコンやタグの情報はサーバ機に送られ、サーバ機はその情報に基づき位置情報を算出し、さらにその位置情報はビーコン(タグ)のIDと共にデータベースに蓄積されます。
 ユーザアプリケーションはデータベースの位置情報データにアクセスし、ユーザの要求仕様に基づきデータを加工してPCやスマホ上に表示します。代表的なユーザアプリケーションとして、以下の3つが挙げられます。
  1. フロアマップ ― 人・モノの位置をフロアマップ図上に表示
  2. ヒートマップ ― 人の滞留情報を表示
  3. 動線追跡 ― 人・モノの移動を線で表示
 このうち1と2については FileMaker 単体で作成が可能です。 QuickIPS はこの2つを実装した、ユーザによるカスタマイズが可能なテンプレートです。

 尚、動線追跡(オブジェクトトラッキング)は、QuickIPS と TPC_IPS の次々バージョンで搭載する予定です。動線追跡については、本Blogの別稿を参照してください。

QuickIPS デモビデオ

QuickIPS の概要を11分程のビデオにまとめました。


なぜ FileMaker なのか?

   理由は他のツールに比べ少ない工数で、グラフィカルなアプリを作成できるからです。IPSユーザアプリケーションのプロトタイプ開発にも適しています。 以下では、QuickIPS の諸機能を詳しくご紹介します。

散布図グラフを用いたフロアマップ

 下図は FileMaker の散布図グラフ機能を使用したビーコン位置を表示するフロアマップです。 予め位置情報表示用のマップ(画像ファイル)を用意しておき、FileMakerのレイアウト上に取り込み、そのマップ上に散布図グラフを配置しています。
 この方法はメリットは、後述する座標データを丸める必要が無いこと、作成が簡単なことですが、ビーコンが近接して検知されるとビーコン名が重なったり、細かいビーコン情報を表示できない点が難点です。

複数ビーコンが近接して検知されると、ビーコン名が重なってしまう

オブジェクトを用いたフロアマップ

 この方式はユーザが予め定めた座標(定点座標)にSVGスポットアイコン()やビーコン情報オブジェクトを配置しておき、測位されたビーコンの情報をこれらのオブジェクトを使用して表示します。
  散布図方式と異なり、同一座標上の複数ビーコンを表示したり、実座標と異なって表示されているビーコンを赤く表示したり、表示フォントの大きさを変更したり(◀ A ▶ を使用)と、機能をカスタマイズできます。

外部システムを使用する際の測位座標の"丸め"

 TPC_IPS の測位機能は、ビーコン座標を定点座標丸めて算出することができます。
 しかし外部システムと QuickIPS を併用する場合は、外部システムでこの丸め処理を行う必要があります。

例:
図のように定点座標(×)を定めたとします。この時、外部システムが以下のようにビーコンを検知したとします。括弧内はx,y座標です。

<外部システムによる測位座標>
 
ビーコンA(0.2, 1.1)
ビーコンB(3.2, 3.6)
ビーコンC(1.5, 2.1)

 この時、各測位座標から最も近い定点座標(×)を各ビーコンの座標と決定します(丸め処理)。ビーコンA(0.2, 1.1)は定点座標(1, 1)に丸め、B(3.2, 3.6)に(3, 3)に、C(1.5, 2.1)は定点座標(2, 2)に丸めます。
注:
 最も近い定点座標(最近傍点)を求めるにはプログラムを自作する手もありますが、K-nearest neighbor(k = 1)のライブラリがあれば、これを使用すると楽ちんと思います。FileMakerで knn なカスタム関数を作成し、外部データベースからデータを取り込む際にこの関数を当てて丸め処理を行うことも可能かもしれませんが、かなり大変と思います。 Brian Dunning氏のカスタム関数公開サイトにはknnなカスタム関数は見当たりませんでした。
 ちなみに TPC_IPS の測位アルゴリズム・TCOTは三点測位的な座標算出を行うため、元の測位座標は定点座標とはほぼ100%一致しません。このため TCOT実行時に、scikit-learn の KNeighbors により定点座標に丸めるオプションを用意しています。

オブジェクトを用いたヒートマップ

 ヒートマップは、人・モノが多く集まる場所を色分けして表示します。ヒートマップも測位座標の丸めを行う必要があります。

青、黄色、赤の順で人・モノの密集度を表示

エラーグラフ

 エラーグラフは静止した状態のビーコンの実座標と測位座標との誤差を折れ線グラフで表示します。 この機能は測位システムの技術担当者が、測位の精度を調べる際に有用な機能となります。

横軸がスキャン実行時刻、縦軸に誤差、誤差値が小さい程、測位精度は高い
 
 グラフに表示するビーコンをピッカー(後述)で選択すると、[Time]で指定した時間の範囲内で測位誤差が縦軸に表示されます。

 IPS導入テスト時には、運用に耐えうる測位精度が得られるかチェックを行いますが、本機能はその際に有用です。 また、屋内環境の変化によっても測位精度は変化するため、適時この機能を使用し、測位精度をチェックするようにします。

注:
 AUTOモードで自動更新ボタン実行中、またはMANUALモードで更新ボタンをクリックした際は、エラーグラフは最新の測位情報により更新されます。

QuickIPS の基本操作について

 QuickIPS の基本操作について簡単に説明します。

AUTO、MANUAL、HISTORYの3モードについて


 QuickIPS には AUTO、MANUAL、HISTORY の3つのモードがあります。各モードは、下図の"実行モード"をクリックしてプルダウンメニューから選択します。

AUTOモード

ボタンが画面右上に表示されるので、これをクリックするとフロアマップ、ヒートマップ、エラーグラフを最新のデータにより自動的更新します。■をクリックすると、自動更新を停止します。

MANUALモード

 このモードはAUTOモードとは異なり、自動更新されません。最新情報で更新するには、画面右上に表示されるをクリックします。

HISTORYモード

 このモードでは過去の座標データを基にフロアマップ、ヒートマップ、エラーグラフを表示することができます。

ヘッダ部

 画面上部のヘッダー部の操作方法について説明します。

サブメニューボタン

クリックするとポップアップメニューが表示されるので、以下を選択。

Scatter map(散布図グラフを使用したフロアマップ)
Floor map(オブジェクトを使用したフロアマップ)
Heatmap(ヒートマップ)
Error graph(距離誤差グラフ)
実行モード

上述のAUTO、MANUAL、HISTORYから選択。

Time ScanCode (YYMMDDMMDDSS形式、スキャンを実行した日時)を範囲指定する。
注:
ScanCode はTPC_IPS を使用する際は自動的生成される。
ScanCodeナビゲーション

[Time]で指定した範囲で、ScanCode 間を移動・選択するためのボタン群
 |<:最初へ移動
 >:  次へ移動
 <:  前へ移動
 >|:最後へ移動

ピッカーボタン 対象となるビーコン及び ScanCode を選択するためのピッカー・フローティングウインドウ(後述)を表示。
エラーサマリーボタン 測位誤差の詳細を表示するエラーサマリー・フローティングウインドウ(後述)を表示。

ピッカー フローティング ウインドウ

 本ウインドウは、フロアマップ、ヒートマップ、エラーグラフで対象とするビーコンや ScanCode を選択するためのウインドウです。本ウインドウは×ボタンで閉じられるまで、常に最前面に表示されます。


ビーコンリストビーコン一覧、クリックで選択あるいは選択解除。選択中のビーコンはピンクで表示される。 選択されたビーコンは、フロアマップの表示対象となる。Error Graph(測位誤差グラフ) で表示されるビーコン数は6つまで。
ビーコン名書式

クリックすると、フロアマップに表示されるビーコン名の書式が切り替わる。
Name: ビーコン名のみ表示
M-M/Name: Major-Minor及びビーコン名を表示

All ボタン

全ビーコンを選択

None ボタン

全てのビーコンの選択を解除

ScanCodeリスト

[Time]で指定された範囲内の ScanCode の一覧。クリックして選択すると、その ScanCode を持つ座標データに基づき、フロアマップとヒートマップが表示される。

エラーサマリー フローティングウインドウ

 エラーサマリーフローティングウインドウは、ピッカーを使用して選択したビーコンの測位誤差のサマリーを表示します。エラーグラフの折れ線は一度に表示できるビーコン数は6つ迄でしたが、このサマリーには選択できるビーコンの数に制限はありません。
 本ウインドウは×ボタンで閉じられるまで、常に最前面に表示されます。 
エラーサマリーフローティングウインドウ
エラーサマリーフローティングウインドウ
 
測位エラーサマリー 静止した状態にあるビーコンの測位誤差をビーコン毎に表示。ビーコンリストから選択されたビーコンの測位誤差の平均、最大、最小、標準偏差を表示。
最終行には選択された全ビーコンの集計値が表示される。集計対象は[Time]で指定された期間。
※ 取得データがない項目には missing が表示される。
エラー種類

エラーの種類を選択するボタン、各ボタン選択時のエラー算出式は以下の通り。
Distance: Sqrt((ax - ex)^2 + (ay - ey)^2)
Coordinates: Abs(ax - ex) + Abs(ay - ey)
注:
・ax, ay: 実座標 x, y
・ex, ey: 測位座標x, y

iPhone/iPadでの使用

 2種類のフロアマップ、ヒートマップ、エラーグラフ機能は iPhone/iPad(iOS) でも利用できます。これらの画面はPC用と同じ画面を使用していますので、工数的に有利な開発が可能です。

iPhone 上での QuickIPS
開発時はPC/iOSでの利用を意識する!

QuickIPS と外部システムとの連携

 QuickIPS には座標データを保存する locLogテーブルがあり、このテーブルのデータを抽出・加工して、上述の機能を実現しています。
 外部システムのデータベースに locLog に対応するテーブルまたはビューがあれば、それから locLogにデータを取り込み、QuickIPS の諸機能を使用することが可能となります。

locLogテーブル構成

 TPC_IPS 以外の外部データベースを使用して QuickIPS を利用する際は、QuickIPS の locLogテーブルに準じて作成します。
フィールド名 データ型 入力 備考
uuid テキスト

必須

ビーコンの uuid

major 数値 必須 ビーコンに割り当てられた major
minor 数値 必須 ビーコンに割り当てられた minor
beaconName テキスト   ビーコン名、検索する場合は入力必須
x 数値 必須 測位されたビーコンのx座標
y 数値 必須 測位されたビーコンのy座標
actual_x 数値   ビーコンの実際のx座標[注1]
actual_y 数値   ビーコンの実際のy座標[注1]
scanCode 数値 必須 スキャン実行タイムスタンプを示す12桁の数値(YYMMDDHHMMSS)[注2]
timestamp タイムスタンプ   レコードが作成された日時

注:
  1. actual_x と actual_y は測位精度テスト時に使用する実際のビーコンの座標です。これらの値と測位された座標の値を使用し、測位誤差が算出されます。
  2. QuickIPS を使用する場合、スキャン毎に生成される scanCode が必要となります。外部システムで scanCode を生成する際は、各センサーが同一のタイミングでスキャンを実行するようにし、スキャン毎に同一の値(YYMMDDHHMMSS)を scanCode に設定してください。例えば、2022/1/1 0:0:0秒にビーコン/タグ信号をスキャンした場合、センサー/受信機のクロックに関わらず、サーバ等で「220101000000」が各レコードの scanCode に入力されるようにします。

外部データベースからlocLogテーブルへのデータ取込

 上表に基づく外部データベースのテーブルデータを QuickIPS の locLog テーブルに取り込むには、以下を行います。
  1. QuickIPS を実行するコンピュータ上で、外部データベースのODBC ドライバにより、所定の DSN を登録
  2. 取り込むテーブル名と loclogテーブルに対応する外部テーブルのフィールド名を指定
  3. 外部データ取込画面で取込を実行

QuickIPS のカスタマイズについて

 前述のオブジェクトを使用したフロアマップは、FileMaker を使用することによってカスタマイズができます。
 下図の要領でカスタマイズを行います。フロアマップの操作はレイアウトモードで行います。
 まず、フロアマップ画像を用意し、フロアマップレイアウトの背景として貼り付けます(最背面)。
 
 つぎに、SVGスポットアイコン、およびビーコン情報オブジェクト(図のピンクの部分、実際は透明)は、それぞれ座標属性を持っているので、座標属性に合わせて配置を行います。 例えば(4, 8)のオブジェクトは、(4,8)のフロアマップ座標上に配置するようにします。 
 
 オブジェクトを配置する際は、配置用オブジェクトの一覧から、対象となるオブジェクトをマウスで選択し、フロアマップレイアウト上にドラッグすることによって配置することができます。下図の例では、 座標(4, 8) のオブジェクト(X-Y が 4-8で示されている)をマウスでドラッグする様子を赤囲みで示したものです。
 SVG スポットアイコンも同様にドラッグコピーで配置します。
 
  大規模施設のフロアマップを作成する場合は、フロアマップ画像を分割し、レイアウト、タブ、スライドを複数作成して、分割したマップをそれぞれに取り込むようにします。

 QuickIPS は FileMaker テンプレートとして単体リリースする予定です。
※ QuickIPS の仕様・予定等は、予告無く変更されることがあります。

 以上
 NuckyT

IPS関連のBlog記事

IPS関連のBlog記事




2020-12-30

IPSのテストベッドをつくる際のTIPS ― デバイスの保護とスマート電源

お知らせ

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

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

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

  当社では Raspberry Pi と ビーコン を使用した IPS(Indoor Positioning System)を開発しています。ソフトウェア開発自体や機器の設定管理等も大変ですが、テストベット(ソフトウェアのテスト・実証環境、長期間、継続的に使用するのが前提)の構築・維持もそれなりに大変です。今回は当社のような小規模組織がIPSテストベットを作る際のTIPSをご紹介します。

テストベッド 

 下図のようなスペースを常時確保できるような大きな企業や研究機関であれば事は簡単ですが、小社のような小規模な会社では日常の労働生活空間とテストベッドを共用することになります。 多数のビーコンのスキャンテストを行う度にRaspberry端末やビーコンを敷設するのは労力も時間も要します。 また、ビーコンや端末を床や机等に長時間放置するのは他の業務の妨げにり、無断で移動されたりすれば、テスト結果が不正確なものとなってしまいます。また、機器の破損も心配です。

図1:当社テストベッド


 今回はテストベッドで使用する ビーコン や Raspberry Pi 設置方法や、電源に関するTIPSをご紹介します。

ビーコンの保護

 ビーコンは屋内と屋外に常設していますが、屋内、屋外を問わず、携帯電話用防水のケースにクッションを入れた上で、その中に収納しています。クッションにより、誤って落下した際に床からの衝撃を吸収させ、ビーコンを守ります。ストラップはスタンド、壁、天井にフックする際に便利です。防水性能ですが、IP規格を取得しているケースを調達します。

IP規格を取得している防水ケース


ビーコンを屋外に常設する

 ビーコンを屋外に常設する際は上記のように防水ケースに入れて、スタンドや地面に設置します。台風、梅雨、秋の長雨の際も放置して良いと思いますが、定期的にチェックするようにしましょう。

地面に設置する際はカラコンを被せるとさらに安心


ビーコンを屋内に常設する

 ビーコンを屋内に常設する場合は他の業務の邪魔にならないように、蹴飛ばされないように、天井から吊り下げます。

誤って落下した場合、ケースとクッションで衝撃を吸収


Raspberry Pi を屋外に常設する

 Raspberry Pi を屋外に常設する場合、IP規格対応の防水ケース入れて電源コードを引きます。


未来工業製WB-10DM、屋外用コンセントの引き込みも可


Raspberry Pi の電源

  図1のような十数台の Raspberry Pi の電源のオン/オフにも意外に手間がかかります。開発・デバッグ中は頻繁に電源のオン/オフが発生することもあり、これが数十台、数百台の規模になると、開発者には地獄です。 Raspberry Pi はWOL (Wakeup On Lan)に対応していないため、マジックパケット送信による遠隔起動はできません。

 そこでスマート電源を使い、iPhone/Android から 電源自体をオンオフできるようにしてあります。

Meross社製スマート電源、Amazonで1500円程度

スマート電源は奥行があるので蹴飛ばされないように配置、ルンバが来ても大丈夫


屋外でスマート電源を使用する

 スマート電源は大きく、屋外の電源コンセントに直接差し込むのは難しいです。その場合、以下のような防水ケースに入れて収納します。複数のコンセントはその先の延長コードに繋がり、その延長コードが Raspberry Pi に接続されます。




外に配置

NuckyT


IPS関連のBlog記事

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