情報処理学会 インタラクション 2019
IPSJ Interaction 2019

2B-43
2019/3/6

IoT センシングサービスプロトタイピングフレームワーク
渡邊恵太†1 赤塚大典†1 関口直紀†2 山口修平†2 宇都宮栄二†3
概要：IoT サービスの研究開発やサービスのための開発フレームワークが多数試みられているが，ハードウェアやネットワーク構成が関係するため，Web 開発のように手軽に参入できるほどのフレームワークがない．本研究では，ハード構成はできるだけ変えずに Web 標準技術やその開発環境を活用しながら，IoT サービスの開発のプロセスを整理し目的の問題解決のための設計や見積もりを低コストで行うフレームワークを提案する．

1. はじめに環境をセンシングしそれらデータをインターネット上にアップロードし解析することによる、通知や予測といったサービスやアプリケーションを開発する IoT サービスの研究開発やサービスのための開発フレームワークが多数試みられている[1]．一方で、こうした IoT サービス設計や開発は、ハードウェアの構成とソフトウェアの構成、さらにネ

図 1

IoT センシングサービス

プロトタイピングフレームワークのプロセス

ットワーク構成といった要素が絡み複雑である．さまざまなフレームワークが提案され，比較検証もされているが，実装したので紹介する．

Web 開発のように誰もが手軽に参入できるほどのフレームワークは未確立である．

2.1 配置比較ツール

こうした不確実な要素が多い環境においてはプロトタ

センサーデータはセンサーの配置位置によって変化する．

イピングが重要となる．プロトタイピングでは，素早いイ

そのため目的のセンサーデータを得るためには，配置の検テレーションによる試行性が重要となるため，ハードの要討が必要になる．一方でセンサーの配置場所は，センシン素検討を最小化しつつソフトウェア上で試行することが望

グ対象や空間に見識のある専門家でなければ，配置場所選ましい．そこで本研究では，スマートフォンをマルチセン定が困難な場合がある．また，専門家であっても，探索的サーデバイスとして捉え，これらを環境や測定したい対象に配置決めを行う場合がある．そこで配置比較ツールは，に配置し，Web 開発のフレームやこれまでの効率的な開発ある場所にセンサーデバイスを配置した際の，データを比モデルである MVC モデルを採用した IoT センシングサー

較し，センサーがデータを取得できているか確認可能にす

ビスプロトタイピングフレームワークを提案する．

る．確認は，各センサーデバイスの変化量を使用し比較する．最低 1 台からできる．1 台の場合は，ある A 地点に設

2. IoT センシングサービスプロトタイピング
フレームワーク
IoT センシングサービスプロトタイピングフレームワークとは IoT センサーとしてスマートフォンを利用し，対象としたい環境内にそれを複数配置し，センシングデータを可視化し，MVC モデルでサービス開発を行う手法である．本手法によって，適切なセンサー配置さえ行えば，個別のセンサーモジュールを意識することなく，ソフトウェア上でセンサー値のイベント化や，意味の定義などのモデル化を行い，サービスの素早い構築が可能になる．ただし，前提として適切なセンサー配置が課題になる．本稿では，適切なセンサー配置を促すためのツール「配置比較ツール」を置した場合と B 地点に設置した場合を置き換えることで，比較する．複数台ある場合には，センサー端末ごとに順位付けを行う．これにより，サービス設計者は変化量の少なすぎる場所や，センサー値がまったくはいってこないセンサーデバイスの配置を別の場所への移動を検討することを支援する．
2.2 センサデータとその取得
現在は，スマートフォンを使用している．またスマーフォンに入ったセンサーデータは Web ブラウザを通じて取得するため，Web ブラウザがサポートしてないセンサーデータは取得できない．また端末によっても搭載していないセンサーがある．現在取得できるデータは，たとえば加速度，磁気（方位），近接センサ，音量（マイク）などがある．こ†1 明治大学†2 株式会社 KDDI 総合研究所†3 KDDI 株式会社© 2019 Information Processing Society of Japan630

情報処理学会 インタラクション 2019
IPSJ Interaction 2019

2B-43
2019/3/6

れらのデータをすべて取得し，各端末はブラウザからサー各センサーデバイスは振動源に近い順に順位を表示した．

バー上へデータを送信する．

これにより設計者は遠いデバイスや場所によるデータの特2.3 実装性による配置判断の探索を支援できる．

実装は Web ブラウザと JavaScript によって行った．スマー

現在，配置比較ツールは変化量を軸として比較するが，トフォンのみならず，たとえば Raspberry Pi などのコンピある時間の総量や最大値や最小値などを軸として評価するュータボードでブラウザが動作すれば，センサーデータを方法もあるだろう．

取得できる．また，リモートオブジェクトとして実装した．

また，場所の探索には，設置したい対象における設置可リモートオブジェクトとして実装することで，遠隔地から能の箇所すべての場所が対象になる．すなわちその表面積そのデバイス上のプログラムを改変できるため，IoT のよに対してデバイス 1 つが占める面積を割る数が，探索可能

うなリモートでのセンシングが発生する環境におけるプロ場所になる．手持ちのセンサーデバイスの数が多いほど探トタイピングにとって出向かず改変が可能になるため，合索の時間は短くなるが，センサーデバイスを準備するコス理的である．

トが高まり，探索時間と金銭コストのトレードオフの関係がある．探索方法はこれから検討してく必要があるが，す2.4 データの可視化と MVC モデル

べての場所を探索比較するには探索所要時間が高まること配置したセンサーからデータを取得したものを可視化する．になり，一方で探索しない場所や，探索したがその時点で設計者は，可視化したデータに基づき MVC モデルにおけは配置不要と判断したことが，あとになって問題にならなるコントローラー部分でさまざまな処理を検討しながら，いかといった問題がある．

サービスを構築していく．より意味のある挙動の関数が定

他に，データ種類の特徴によっては配置の考え方も変わ

義できそうであればそれはモデルとして構築していく．たってくる．たとえば，ドアを開けたことを検知する仕組み

とえば，ドアの開閉をサービスとして使用したい場合には，をつくるといった場合は「ドアの開閉」という挙動に対す

以下のように記述する

るデータであることを教師ありデータとして設計者は理解できる．一方で，何かが起こるが何がおきるかは起きてみ■デバイスの振る舞い（コントローラ）
class DoorSensor{
isOpen(){if(compassmaxValue > 2000){
return true}else{
return false}}}■アプリケーションロジック（モデル）
const thing = new Thing(DoorSensor, config);
if(thing.isOpen()){
document.querySelector(“#door”).innnerHTML = “open”}else{
document.querySeelector(“#door”).innterHTML = “close”}■画面表示，デザイン（ビュー）<style>#door{

ないとわからないような場合がある．
3.2 IoT サービスの見積もりの簡略化
IoT サービスを構築する場合，ある目的が定まっていたとしても，それが可能であるかどうかはハードウェアの選定や，ネットワーク環境，ソフトウェア構築の見積もりが必要になる．本研究では，目的に応じてハードウェアを構成しない戦略をとる．複数のセンサーセットは何をセットにするかは議論であるが，複数のセンサーを搭載することで，どれかが反応することを前提として，配置箇所の問題とソフトウェア上での試行錯誤によって，センサー値の意味を取得できると考える．この方法によって，複雑になりがちな IoT サービスの見積もりを設置対象の面積からどの程度の数のセンサーデバイスを配置するかといった見積もりを立てることができるようになるだろう．

4. おわりに本研究では IoT サービスの設計や見積もりを低コストでの

font-size: 2em;}</style><div id=”door”></div>

実現を目指した IoT センシングサービスプロトタイピング
フレームワークについて紹介した．今後は長期利用を通じて課題点を整理し，実用的に利用可能なものを目指す．

参考文献

3. 考察・議論
3.1 配置探索の試用
机の上に振動源を配置し，センサーデバイスを配置した．

© 2019 Information Processing Society of Japan[1]

Developing IoT applications: challenges and frameworks,
Udoh,Itorobong S. et al.IET Cyber-Physical Systems: Theory &Applications(2018), 3 65 http://dx.doi.org/10.1049/ietcps.2017.0068

631