今回は前二稿とは趣を変え、モバイル端末を物品に取り付けることによってその位置を適時把握するモデルを考えるとともに、そのモデルに則したプロトタイプを作成・試用してみました。
多数移動体位置監視モデル
本モデルでは、数十～数百、数千の移動する商品、物品、人などの物体に モバイル端末を取り付け、地図上にその所在地を表示しています。
下図のように、モバイル端末のインターネット接続にはMVNOが提供する移動体通信網を使用し、端末はGPSにより得られた自身の位置情報をアプリケーションサーバ経由でDBサーバに送ります。DBサーバは送られてきた端末の位置情報を保存します。また、各端末の位置の地図上表示も、PC等のブラウザからアプリケーションサーバを介して行います。
下図のように、モバイル端末のインターネット接続にはMVNOが提供する移動体通信網を使用し、端末はGPSにより得られた自身の位置情報をアプリケーションサーバ経由でDBサーバに送ります。DBサーバは送られてきた端末の位置情報を保存します。また、各端末の位置の地図上表示も、PC等のブラウザからアプリケーションサーバを介して行います。
 |
| 図1 ― モデル概要 |
通信端末について
当初、上図端末には Raspberry Pi 等のシングルボードコンピュータを使用する予定だったのですが、検討を進めていくうちにコスト増のモデルになり得ることがわかりました。
具体的には、まず、ラズパイにSIMドングルやGPSモジュール（ドングル）を載せる必要が出てくるわけですが、実用面を考慮するとユーザに容易にシャットダウンしてもらうための電源On/Offスイッチ、電源供給が遮断された場合に備え、UPSも準備する必要があります。
これらのモノは全て自前で調達して設定しなければならないため、価格、性能評価や設定の労力、携帯性、収納性等がネックとなります。ラズパイは途中まで設定やテストを行ったのですが、結局 Android 端末を使用することにしました。
Android であれば All-in-One で低価格（￥5千前後～）で入手でき、携帯性・耐衝撃性(移動時にコネクタ/ケーブル類が外れる可能性がほぼ無い)に優れ、電源周りで気を遣うことがなく、安定性・信頼性も実績十分です。
具体的には、まず、ラズパイに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 の実際の使用感については後述します。
ただ、今回作成・テストするプロトタイプシステムでは、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 側にあまり仕事をさせないのは、通信量を抑えるというコスト上の理由と、外部で使用するモバイル端末から送信する情報の量は必要最低限にするというセキュリティ上の理由によります。
プロトタイプのテスト
上記の仕様に従ってそれぞれのアプリケーションを作成し、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 実行画面 |
 |
| 図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
ただ、今回の 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 クライアントでの利用
0 件のコメント:
コメントを投稿