修士論文 スケーラビリティを考慮した センサ駆動アプリケーションフレーム

NAIST-IS-MT0651023
修士論文
スケーラビリティを考慮した
センサ駆動アプリケーションフレームワーク
大西 洋司
2008 年 2 月 7 日
奈良先端科学技術大学院大学
情報科学研究科 情報システム学専攻
本論文は奈良先端科学技術大学院大学情報科学研究科に
修士 (工学) 授与の要件として提出した修士論文である。
大西 洋司
審査委員：
松本 健一 教授
（主指導教員）
伊藤 実 教授
（副指導教員）
門田 暁人 准教授
（副指導教員）
中村 匡秀 准教授
（神戸大学）
スケーラビリティを考慮した
センサ駆動アプリケーションフレームワーク∗
大西 洋司
内容梗概
近年のセンサ機器の発達により，センサの状態を監視し，センサの値があらか
じめ指定した条件に一致したときに何らかの処理を行うというセンサ駆動サービ
スが普及しつつある．しかし，利用するセンサの個数が増加すると，多数のセン
サを同時に扱うアプリケーションが複雑になるというセンサとアプリケーション
の密結合の問題や，センサから取得されるデータが膨大になりネットワークやア
プリケーションの負荷が増大するといったスケーラビリティの問題点が発生する．
本論文では, これらの問題を解決するスケーラビリティを考慮したセンサアプリ
ケーションフレームワークを提案する．提案フレームワークでは，センサにサー
ビスレイヤを持たせ，センサ固有の情報を扱い，処理をすべて行わせることで，
アプリケーションの密結合の問題を解決した．それに加え，Publish/Subscribe 型
のメッセージ交換パターンをベースとした通信を用いることで通信やアプリケー
ションの負荷を軽減させることができた．また，提案フレームワークを実装し，
上記の問題点が解決できていることを実験により確認した．
キーワード
センサ駆動サービス, センサミドルウェア, イベント駆動, 疎結合, 負荷分散
∗
奈良先端科学技術大学院大学 情報科学研究科 情報システム学専攻 修士論文, NAIST-ISMT0651023, 2008 年 2 月 7 日.
i
An Implementation of Scalable Sensor
Application Framework∗
Yoji Onishi
Abstract
Many integrated services with sensors and its appliances become common in
our daily life. In most of those services, the application and sensors are tightlycoupled. This causes the implementation of the application becomes more complicated. Moreover, network load between the application and the sensor and
processing load to evaluate the sensor data increase severely. As the number of
sensors to connect increases, the problems become more serious.
This paper proposes a scalable sensor application framework. Using a standardized API, applications can access any sensors without implementing any
sensor-specific procedure. Furthermore, the application delegates a part of evaluation process of the trigger conditions to the sensor. Due to the delegation,
network load is minimized because the application communicates with the sensor
only when the status of the registered condition is changed. Using these methods,
we evaluate this framework by measuring network load.
Keywords:
sensor driven service, sensor middleware, event driven, loose coupling, load balancing
∗
Master’s Thesis, Department of Information Systems, Graduate School of Information
Science, Nara Institute of Science and Technology, NAIST-IS-MT0651023, February 7, 2008.
ii
関連発表論文
国際会議
1. Yoji Onishi, Hiroshi Igaki, Masahide Nakamura, and Ken-ichi Matsumoto.
A Scalable Sensor Application Framework Based on Hierarchical LoadBalancing Architecture. In Proceedings of the IASTED International Conference on Software Engineering (IASTED SE 2008), pp.37-42, February
2008.
研究会・シンポジウム
1. 大西洋司, 前島弘敬, 西澤茂隆, 田中秀一郎, 中村匡秀, 松本健一. 時間駆動
型 Web サービス呼び出しフレームワーク WS-Schedule Manager の提案と
実装. 電子情報通信学会技術研究報告, Vol.106, No.578, pp.459-464, March
2007.
iii
その他の発表論文
国際会議
1. Yasutaka Kamei, Shinsuke Matsumoto, Hirotaka Maeshima, Yoji Onishi,
Masao Ohira, and Ken-ichi Matsumoto. Analysis of Coordination between
Developers and Users in the Apache Community.
In Proceedings of the
International Conference on Open Source Systems (OSS2008), September
2008, (to appear).
研究会・シンポジウム
1. 前島弘敬, 大西洋司, 中村匡秀, 松本健一. BPEL ワークフローに着目した
連携 Web サービスの応答速度・稼働率の見積もり手法. 電子情報通信学会
技術研究報告, Vol.106, No.578, pp.465-470, March 2007.
2. 大蔵君治, 大西洋司, 川口真司, 大平雅雄, 飯田 元, 松本健一. メールス
レッドのクラスター分析による OSS プロジェクトのアクティビティ予測手
法. 電子情報通信学会技術研究報告, vol.107, No.275, SS2007-37, pp.41-46,
October 2007.
3. 前島弘敬,
×本真佑, 亀井靖高, 柿元 健, 大西洋司, 大平雅雄, 松本健一.
コーディネータのコミュニティ媒介性の評価指標の提案. 情報処理学会シ
ンポジウム, Vol.2007, No.11, pp.71-76, November 2007.
iv
目次
1. はじめに
1
2. 準備
4
2.1
センサ駆動サービス
. . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2
センサの定義 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.3
センサ駆動条件の定義 . . . . . . . . . . . . . . . . . . . . . . . .
6
2.4
条件の記述
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.5
従来のセンサアプリケーションにおける問題点 . . . . . . . . . . .
9
3. 提案フレームワーク
11
3.1
キーアイデア . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.2
センサへの標準的なインタフェースの提供 . . . . . . . . . . . . .
11
3.3
センサへの条件登録による条件判定処理の委譲 . . . . . . . . . . .
12
3.4
メタセンサの導入 . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.5
フレームワークの動作 . . . . . . . . . . . . . . . . . . . . . . . .
19
3.6
実装 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
4. 評価実験
23
4.1
評価の概要と目的 . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
4.2
実験環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
4.3
実験手順 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.4
結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
5. 考察
30
5.1
フレームワークの特徴 . . . . . . . . . . . . . . . . . . . . . . . .
30
5.2
フレームワークの限界 . . . . . . . . . . . . . . . . . . . . . . . .
33
5.3
先行研究との比較 . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
6. おわりに
36
v
謝辞
37
参考文献
39
付録
41
A. BNF 記法によるルール記述
41
B. センサ駆動アプリケーションのメソッドとその引数
42
B.1 クライアントアプリケーション . . . . . . . . . . . . . . . . . . .
42
B.2 サービスレイヤ . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
B.3 センサ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
B.4 メタセンサ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
B.5 ConditionSet . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
B.6 AtomicCondition . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
vi
図目次
1
環境条件の BNF による表現 . . . . . . . . . . . . . . . . . . . . .
7
2
従来のセンサアプリケーション . . . . . . . . . . . . . . . . . . .
9
3
標準的なインタフェースの提供 . . . . . . . . . . . . . . . . . . .
12
4
センサへの条件登録
. . . . . . . . . . . . . . . . . . . . . . . . .
13
5
メタセンサの構造 . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
6
従来のセンサ駆動サービスのシーケンス図 . . . . . . . . . . . . .
17
7
提案フレームワークのシーケンス図 . . . . . . . . . . . . . . . . .
17
8
メタセンサのシーケンス図 . . . . . . . . . . . . . . . . . . . . . .
18
9
実装した提案フレームワークのクラス図 . . . . . . . . . . . . . .
21
10
実験機の構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
11
Phidgets 力センサ . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
12
Phidgets ライトセンサ . . . . . . . . . . . . . . . . . . . . . . . .
26
13
実験で使用した条件文の Java 言語による実装 . . . . . . . . . . .
28
表目次
1
センサにおける型制約 t の種類
. . . . . . . . . . . . . . . . . . .
5
2
環境属性値の実環境における値と計測数値との違い . . . . . . . .
7
3
利用できる 2 項演算子とその意味 . . . . . . . . . . . . . . . . . .
8
4
利用できる関係演算子とその意味 . . . . . . . . . . . . . . . . . .
8
5
実験機環境
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
6
実験環境 (ソフトウェア) . . . . . . . . . . . . . . . . . . . . . . .
25
7
Phidgets センサの仕様 . . . . . . . . . . . . . . . . . . . . . . . .
25
8
実験フェーズ . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
9
結果 (従来法) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
10
従来法における速度の平均時間 . . . . . . . . . . . . . . . . . . .
30
11
結果 (提案法) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
12
提案法における速度の平均時間 . . . . . . . . . . . . . . . . . . .
32
vii
1. はじめに
組み込み技術，ネットワーク技術の進歩に伴い，多様な家電製品や電気機器が
誕生し，人々の生活に深く浸透している．それらの機器はより高性能，高機能に
進化しているだけでなく，複数の機器同士を連携させて動作する機能が普及して
きた [1, 2, 3]．また，機器同士の連携に限らず，センサと機器を組み合わせてより
知的に動作する連携機能の開発・普及が進んでいる．ユビキタスコンピューティ
ングの分野では特に，ユーザの挙動や環境の変化をセンサにより検知し，事前に
登録された条件に適合した場合にサービスを駆動するセンサ駆動型のアプリケー
ションの開発が実際に行われている．
例えば，ホームネットワークシステムやビル管理システムでは，センサと組み
合わせて動作することを前提とした機器が数多く運用されている．人感センサを
利用し，人が近くに来るとライトをつけるセンサライト [4]，人が近づくとドア
を開ける自動ドア [5] や，温度センサを利用して空調を適度に保つエアコンの自
動運転制御 [6]，手をかざすことで水道の蛇口が開く自動水栓 (automatic sensor
faucet)[7] などが存在する．また，より高度な例では，ユーザの血圧や薬を定期的
に摂取しているか，倒れたりしていないか等のデータをセンサによって取得し，
家族など介護を行っているユーザや救急車を呼ぶといった，ユーザの状態に適し
た行動を選択・決定し実行する生活支援システムなどが提案されている [8]．この
ように，ユーザの周囲に複数のセンサとそのセンサを利用する複数のユビキタス
アプリケーションが配備されるようになりつつある．
このようなセンサ駆動型アプリケーションにおいてよりきめ細やかなサービス
をユーザに提供しようとした場合，機器に接続するセンサを増やし，周囲環境の
情報を多数集めることで改良することができる．しかし，現状では機器に接続す
るセンサを増やした場合，2 つの問題点が発生するため，実現が難しい．
1 つ目の問題は，センサと機器が密に結合している点である．センサを扱うア
プリケーションがセンサの値を得ようとした場合，センサへのアクセス方法やセ
ンサの値の解釈といったセンサ固有の処理をアプリケーション内に作り込む必要
がある．そのため，センサが増加するとアプリケーションの複雑さが増大し，セ
ンサの追加・変更時のアプリケーションの改修コストが大きくなってしまう．
1
2 つ目の問題は，接続するセンサの数を増加させることに対するスケーラビリ
ティが低い点である．センサが検知する値は，環境の変化に伴って変化し続ける．
センサを利用するアプリケーションは絶えずその値を監視し続けている必要があ
るため，センサ数の増加に伴い，センサとアプリケーション間の通信量やセンサ
データを処理するアプリケーションの負荷も増大する．
そこで，本論文では多数のセンサを利用するようなユビキタスサービス実現に
おいて考慮が必要なこの密結合の問題 (問題 1) とスケーラビリティの問題 (問題
2) に対応したスケーラブルなセンサアプリケーションを構築可能にするフレーム
ワークを提案する．
まず問題 1 に対応するために，センサデバイスをサービスレイヤと呼ぶ層で包
み込む．このサービスレイヤはセンサ固有のアクセス方法や値解釈に関するロ
ジックを Web サービス技術 [9] を利用した標準的な API に変換するラッパーで，
センサとアプリケーション間の疎結合を実現する．ユビキタスサービスは，この
サービスレイヤを通じて，各センサが検知可能なプロパティの情報と，そのプロ
パティの値を取得し，アプリケーション内でセンサ固有のロジックを記述するこ
となく多様なプラットフォームから簡単に利用することが可能となる．
問題 2 に対しては，サービスを駆動するための条件がセンサの示す値の閾値か
ら構成されるケースが多いことに着目し (例えば温度計の場合，温度が 27 度以上
になったら冷房の電源を入れるなど)，この種の条件判定をアプリケーションでは
なく各センサのサービスレイヤに委譲する仕組みを作成した．アプリケーション
はサービスレイヤを通して，センサごとに条件を登録 (subscribe) する．各サー
ビスレイヤは登録された条件にもとづいてセンサの値を監視し，条件が成立した
とき，または不成立になったときのみ，それぞれ真/偽という返答をアプリケー
ションに通知 (publish) する．このような Publish/Subscribe 型のメッセージ交換
パターン [10] を応用したアーキテクチャにより，センサとアプリケーション間の
通信が登録された条件が成立/不成立のときしか行われなくなる．結果として，問
題 2 で述べた通信コストの問題は大いに改善される．また，条件判定の部分がセ
ンサに委譲されるため，アプリケーションの負荷も低減される．
さらに，提案するサービスレイヤを利用することで，複数のセンサの取る閾値
2
を組み合わせた複雑な条件を検知するメタセンサを容易に実装することが可能と
なる．例えばエアコンの自動運転制御では，
「室温が 28 度以上かつ湿度が 50%以
上のときに強運転を行う」といった，複数のセンサをまたがった条件を記述する
ことができる．
本論文では，提案するフレームワークを用いてセンサ機器と家電機器とを対
象としたセンサ駆動サービスを提供するアプリケーションを開発し，センサの入
れ替えやユーザ要求の変化，サービス内容の修正への対応が可能であることと，
センサとアプリケーションとの間の通信量がどの程度削減されるかをケーススタ
ディとして行った．
以降，第 2 章でセンサ駆動サービスの定義と問題点を説明し，第 3 章で提案フ
レームワークを説明する．第 4 章で実際に実装されたフレームワークの負荷を従
来法と実験的に比較し，第 5 章で考察を行い，第 6 章でまとめを行う．
3
2. 準備
2.1 センサ駆動サービス
センサ駆動サービスとは，環境の状態を数値化するセンサデバイス (sensor de-
vice) から値を取得し，その値があらかじめ決めておいた条件に一致したときに，
あらかじめ決めておいた機器を駆動させるサービスである．センサデバイスの種
類は多様にあり，温度センサ，人感センサ，赤外線距離センサなどがある．セン
サデバイスごとに取得できる情報は異なり，温度センサであれば温度の値，人感
センサであれば人の存在の有無，赤外線距離センサであればセンサからセンサに
近い物体への距離が得られる．それぞれのセンサは温度や距離といった単一のプ
ロパティを保持し1 ，そのプロパティが取得できる値の範囲内で，そのプロパティ
がとる環境属性値 (environmental value) を監視する．
このようなセンサ駆動サービスについての定義と詳細な説明を，次節以降で述
べる．
2.2 センサの定義
1 つのセンサ駆動サービスで用いられるセンサデバイスを式 (1) と定義する．
si ∈ S(1 ≤ i ≤ n)
(1)
式 (1) において，s は単一のセンサデバイスを表し，S は 1 つのセンサ駆動サー
ビスで用いられているセンサデバイスの集合を表す．各センサデバイス si はそれ
ぞれ 1 つのプロパティp を持ち，プロパティp に基づいた値を取得することができ
る．またプロパティp はそれぞれ型制約 tv と呼ばれる，センサが取りうる値の種
類（例えば，整数型をとる，真偽のいずれかをとるなど）とその範囲の制約を持
ち，型制約 tv に基づいたセンサ値 v を取る．
1
センサによっては，1 つのセンサに複数のプロパティを保持するものも存在する．そのよう
な場合，そのセンサは 1 つのプロパティを持つ複数のセンサの集まりとみなすことができる．
4
表 1 センサにおける型制約 t の種類
型名
型
制約の要素
表記の例
integer
整数型
最小値と最大値をとる
int{0, 100}
f loat
浮動小数点型
最小値と最大値をとる
f loat{3.5e − 2, 7.0e − 3}
string
文字列型
文字列をとる
str
enumerate
列挙型
選択できる要素の組のうち
enum{“weak 00 , “middle00 ,
1 つをとる
“high00 }
true もしくは f alse をとる
bool
boolean
ブール型
一般的に，環境属性値はセンサ値 v とは異なった数値をとる．異なるベンダか
ら開発されたセンサはそれぞれ仕様が異なるため，センサ値 v を人間が解釈しや
すく，条件記述において用いやすい表現である環境属性値 e に変換するための機
能をセンサに合わせて開発しなければならない．すなわち，多くのセンサ s は式
(2) に示すような，測定したセンサ値 v を環境属性値 e に変換するための関数 f を
持つ．
e = f (v)
(2)
また，センサ値 v に型制約があるのと同様に，センサから得られたセンサ値 v
をセンサ固有の関数 f で変換した環境属性値 e にも型制約 te がある．これらの型
制約の種類を表 1 に示す．
Phidgets[11] の温度センサの例を考える．Phidgets の温度センサ s は温度とい
うプロパティp を持つ．プロパティp は型制約 tv = int{40, 700}(整数型をとり，40
から 700 の間の値を取ることを表す) を持ち，その制約の中でのセンサ値 v をと
る．もしアプリケーションが温度センサを用いて温度 p を取得しようとした場合，
まずアプリケーションは温度センサからセンサ値 v を取得し，式 (3) のような値
変換の関数によってセンサ値から環境属性値に値を変換する必要がある．
5
v − 200
(3)
4
また，式 (3) で得られた環境属性値 e は，型制約 te = int{−40, 125} を満たす．
e = f (v) =
環境属性値 e は，センサのプロパティp における単位系による制約と，センサデ
バイスの性能による制約といった 2 つの制約を受けることで，とりうる値の範囲
がセンサごとに変化する．例えば，センサのプロパティp が温度の場合，単位系に
よる制約として −273◦ C 未満にはならないといったものがある．Phidgets[11] の
温度センサであれば，センサ値の型制約 tv と変換関数 f から te = int{−40, 125}
という制約があることが分かる．
2.3 センサ駆動条件の定義
センサアプリケーションにおけるセンサの主な役割は，現在の環境属性値を取
得することである．アプリケーションはあらかじめセンサ駆動サービスに登録さ
れた駆動条件に基づいて機器を駆動させるために，登録されたセンサを監視し，
環境属性値の変化を監視している．駆動条件が真か偽になったかどうかを評価す
るために，アプリケーションは継続的にセンサと通信を行う．
本論文では，環境条件を式 (4) で定義する．
E = {e1 , e2 , ..., en }
(4)
E は環境属性の組を表し，単一の環境属性 e の組で表される．また，atom(e)
を単一の環境属性値 e に依存した論理式と定義し，環境属性の組 E の環境条件を
condE と定義する．また，すべての環境条件 condE は atom(e) の組み合わせで定
義される，図 1 のバッカス・ナウア記法 (BNF)[12] で表される．これらの e，E ，
atom(e)，condE の関係を表 2 に示す．
センサ駆動サービスは環境条件と動作の組で表される．例えば，センサライト
サービスは式 (5) のような条件と動作を持っていると考えられる．
condE : ”human detect == true && brightness < 10”
action : ”turn on the light”
6
(5)
condE ::
condE && condE
(AND)
condE || condE
(OR)
! condE
(NOT)
(condE)
atom(ei )
図 1 環境条件の BNF による表現
表 2 環境属性値の実環境における値と計測数値との違い
単位環境属性 環境属性の組
実環境の環境属性値
e
E
計測・記述される値
atom(e)
condE
式 (5) では，human detect センサが true の値をとり (人を検知し)，brightness
センサが 10 ルクス未満の値をとる (暗くなる) と，動作 ”turn on the light” を呼
び出すという条件を意味している．
一般的に，上記のような条件文における動作 (action) は家電統合サービスや他
の API 呼び出しなどのメソッド呼び出しの組を持つアプリケーションを呼び出す
ことによって実行する．本論文では，動作条件の登録部分のみに焦点を当て，呼
び出した後の動作についての詳細には焦点を当てないこととする．
2.4 条件の記述
センサ駆動サービスでは，登録された機器を駆動させるために，機器の駆動条
件があらかじめ登録されており，センサから得られた値をその条件文に代入する
ことによって条件文の真偽を判定している．
まず，1 つのセンサに対する条件文を考える．センサに対する条件文を記述す
る際は，そのセンサから得られたセンサ値が，あらかじめ決められた値と比較す
ることで条件文の真偽が判定される．単一のセンサに対する条件文の記法を式 (6)
7
表 3 利用できる 2 項演算子とその意味
2 項演算子 意味
<
左辺が右辺よりも小さい
>
左辺が右辺よりも大きい
<=
左辺が右辺よりも同じか小さい
>=
左辺が右辺よりも同じか大きい
==
左辺と右辺が等しい
!=
左辺と右辺が異なる
eq
左辺と右辺も文字列が一致する
表 4 利用できる関係演算子とその意味
関係演算子 意味
x && y
x || y
x と y の両方が成り立てば成り立つ
x と y のうち一方が成り立てば成り立つ
に示す．
atom(e) = sensor name operator value
(6)
sensor name は，今注目しているセンサの固有 ID を示し，value は比較する値
を示している．演算子 (operator) には表 3 に示す 2 項演算子が考えられる．セン
サでは，実際にこのような条件式にセンサ値を代入することで条件文を判定し，
機器を駆動するかどうかを決定している．
複数のセンサについての条件文を記述するには，式 (6) で示すセンサごとの条
件文を表 4 に示す論理演算子で組み合わせることで式 (7) のような記法で記述す
ることができる．
condE = atom(e) operator atom(e)
(7)
なお，単一のセンサに対する条件文 atom(e)，複数のセンサに対する条件文
8
Sensor Device A
Sensor Device B
file
Sensor Device C
API
Get
current
value v
i
10
Get
API
14
13
Get
・・・
Read
0.7
0.5
0.4
Read
Read
・・・
true
Get
Get
true
false
Get
・・・
Sensor Value vA
Sensor Value vB
Sensor Value vC
Value Converting
function f
Value Converting
function f
Value Converting
function f
A
Environmental Value eA
B
C
Environmental Value eB Environmental Value eC
Application
図 2 従来のセンサアプリケーション
condE の詳細な記法については，付録 A で示した．
2.5 従来のセンサアプリケーションにおける問題点
従来のセンサ駆動サービスを用いたセンサアプリケーションの模式図を図 2 に
示す．
図 2 において，センサデバイスからセンサ値を得る方法はセンサごとに異なる．
センサデバイスに固有の API が用意されていたり，最新のセンサ値がファイルと
して保存されており，そのファイルにアクセスすることでセンサ値を得られると
いったセンサへのアクセス方法がある．また，センサ値の型制約 tv がセンサデバ
イスごとに異なる点，センサ値 v を環境属性値 e に変換するための変換関数 f が
センサデバイスごとに異なる点のために，センサデバイスにアクセスするための
アプリケーションの仕様もセンサデバイスごとに異なる．これらのセンサデバイ
9
ス間の違いはアプリケーションの違いに直接的に影響を与えてしまう．そのため，
アプリケーションの開発者は以下の 2 つの問題点に直面する．
問題 1: センサとアプリケーションの結合が密
問題 2: スケーラビリティが低い
アプリケーションで使われるセンサの種類は，そのセンサ駆動サービスの内容
に依存する．サービスの駆動条件や振る舞いを更新したり，センサを交換したり
しようとした場合，開発者はアプリケーションに含まれているセンサ固有の記述
と条件を更新しなければならない．そのため，問題 1 に示すように，センサ固有
の情報がアプリケーションに含まれていることから，アプリケーションの複雑さ
が増加し，センサ駆動サービスの柔軟なカスタマイズ性を妨げてしまう．
問題 2 の低いスケーラビリティは，アプリケーションのネットワークの負荷と
条件判定処理の負荷に起因する．センサ駆動サービスの数と種類が増加するにつ
れ，1 つのセンサが多くのアプリケーションから使われることになる．図 2 に示
すように，アプリケーションは継続的にセンサから値を取得しなければならない．
アプリケーションはセンサで検知した値を監視し続け，センサ駆動サービスの駆
動条件に一致する動作を実行するために環境条件を評価し続けなければならない．
その結果，非常に多くのセンサが頻繁にアクセスされ，アプリケーションが多く
の条件判定処理を行うため，ネットワークと条件判定処理のパフォーマンスが悪
くなってしまう．
3 章以降では，これらの問題を解決するセンサアプリケーションフレームワー
クについて説明する．
10
3. 提案フレームワーク
3.1 キーアイデア
2 章で述べた問題点を解決するために，提案フレームワークでは次の 3 つのキー
アイデアを用いる．
1. センサへの標準的なインタフェースの提供
2. 条件判定ロジックをセンサへ委譲
3. サービスレイヤの階層化によるメタセンサの実現
提案フレームワークでは，センサ固有の情報であるセンサ値 vi や変換関数 fi
をアプリケーションで扱うのではなく，新たにセンサにセンサ固有の情報を扱う
サービスレイヤを設置し，そこでそれらの情報をすべて扱うこととする．これに
より，アプリケーションはセンサ固有の情報やロジックを知らずとも，環境情報 ei
のみを扱えるため，センサとアプリケーションの結合度を弱くすることができる．
また，センサ固有の情報や処理だけでなくセンサ駆動サービスの条件判定もサー
ビスレイヤに委譲する．このことにより，アプリケーションにおける条件判定の
負荷やネットワークの負荷を低減することができるようになる．さらに，複数の
センサを用いる条件文を簡易に扱えるようにするため，メタセンサを提案する．
これらのキーアイデアについて，次節以降で説明する．
3.2 センサへの標準的なインタフェースの提供
サービスレイヤを用いた提案センサの構成を図 3 に示す．サービスレイヤでは，
センサ si が持つセンサごとに固有の情報であるプロパティ名 pi や型制約 tvi ，セ
ンサ値 vi を保持し，これらの情報はサービスレイヤ内でのみ扱う．センサは，ア
プリケーションに対して，環境情報 ei のみを共通インタフェース getStatus() を
用いて提供する．アプリケーションは，条件判断に不要な型制約 tvi やセンサ値
vi ，変換関数 fi を知ることなく環境情報 ei のみを用いることができるため，セン
11
v
Sensor Device
f
Service Layer
i
i
e
i
getStatus()
Get the current
e
value e
i
i
Application
図 3 標準的なインタフェースの提供
サとアプリケーション間の依存性を弱くすることができる．また，インタフェー
スが共通であるため，センサを変更してもアプリケーションを再構築することな
く同じアクセス方法を利用して値を取得することが出来る．
3.3 センサへの条件登録による条件判定処理の委譲
3.2 節における getStatus() メソッドによって，センサ固有の情報は知らずとも
センサの環境属性値を取得できるようになった．しかしながら，最新の環境属性
値によって条件の真偽を判定する場合，絶えず getStatus() メソッドを呼び出し，
最新の環境情報値を取得し，条件文が成立するかをアプリケーションが監視しな
ければならない．この現在のセンサ値を取得するための継続的なアクセスによっ
て，ネットワークやセンサの負荷が増大してしまう．提案フレームワークでは，
センサから得られた環境属性値 ei を用いた条件文の真偽値判定をサービスレイヤ
に委譲することでこの問題を解決する．
図 4 では，条件判断を行う処理を追加したサービスレイヤの処理の流れを示し
ている．図 4 において，サービスレイヤに新たに条件を追加するためのメソッド
subscribe() を追加している．subscribe() メソッドは，センサを利用するアプリ
ケーションから，各センサがとりうる環境属性値を用いた条件文とその条件文の
12
Subscribed Conditions
ID condE List
Last Condition
1 brightness>12
true
2 brightness<10
false
…
subscribe()
Sensor Device
e
i
Service Layer
condE evaluator
Tell me when
“brightness < 10”,
ID:2
ID2:true
notify()
Application
図 4 センサへの条件登録
真偽値が変化したときに通知する Web サービス [9] の WSDL [13](条件文を登録し
たアプリケーションの WSDL の場合と，実際に駆動させる家電機器などの WSDL
の場合がある．) を登録するためのものである．サービスレイヤでは，アプリケー
ションから条件が登録されると，継続的に監視しているセンサデバイスから得ら
れた環境属性値を利用して，登録された条件文の真偽値を判定する．そして，条
件文の真偽値の変化に応じて条件と共に登録した登録した Web サービスを呼び
出すことで通知を行う．
センサ駆動アプリケーションにおいて機器を駆動させる場合，ルールに基づい
た機器の駆動パターンとして以下の 2 つの種類がある．
if (condition) then { action }
(8)
while(condition) { action }
(9)
条件文 (8) では，指定した条件文 condition が真になったときに一度だけ動作
action が呼び出される．そのため，センサ駆動アプリケーションでは登録された
13
条件文が真になったかどうかのみを監視し，通知すればよい．それに対し式 (9)
では，指定した条件文が真の状態である間動作 action を駆動させ続ける．これは，
条件が真になったときと偽になったときの 2 回，動作 action を呼び出すことで機
器の駆動を切り替え，条件文に従った機器の駆動を行える．すなわち，式 (9) は
式 (10) のように書き換えることができる．

 if (condition) { start action }
 if (!condition) { stop action }
(10)
これはすなわち，条件文の変化があったときに通知を行うことで，これら 2 つ
の機器の駆動パターンに対応できる．そのため提案フレームワークでは，条件が
真のときのみ通知を行う通常の Publish/Subscribe 型通信 [10] を改良し，条件が
変化したときに通知を行うといった通信を行うこととした．
3.4 メタセンサの導入
機器の駆動条件として単一のセンサのみを用いたセンサ駆動サービスは 3.3 節
で述べたセンサを用いることで実現できる．しかし，よりきめ細やかに環境情報
を取得し，それに応じて動作する機器に通知を行うために，単一のセンサだけで
なく複数のセンサを用いた条件文を記述することによってセンサ駆動サービスを
構築する必要がある．複数のセンサを含む条件を記述する場合，その条件文を解
析し，単一のセンサを用いる条件文に分解しなければならない．そのような機能
を持つ解析器にセンサのサービスレイヤを付加したセンサをメタセンサと呼び，
その模式図を図 5 に示す．
メタセンサは，3.3 節で示した提案センサを 2 つ以上組み合わせ，式 (7) で示す
複数のセンサをまたがる条件式を解釈できるようにしたソフトウェアによるセン
サである．メタセンサにはサービスレイヤに加え，複数のセンサをまたがる条件
を解析する解析器 (divider) と，メタセンサに登録している単体センサから通知を
受け取る notif y インタフェースを備える．またメタセンサは，メタセンサが利用
する単体センサの一覧を保持している．
メタセンサは次の手順で動作・利用する．
14
Atomic Conditions
Subscriber
ID
atom(ei)
sIdA
sIdB
ei
human_detect
== true
brightness<10
…
Human Detect
Sensor（HDS)
Service Layer
Brightness Sensor
（BS)
Service Layer
subscribe()
subscribe()
(2)
human_detect brightness<10
(2)
== true
Registered Sensors
(1)
notify()
divider
si
human_detect
HDS
brightness
BS (http://BS/wsdl)
Meta Sensor
(http://HDS/wsdl)
Subscribed Conditions
condE
Last
ID List
Condition
1 sIdA && sIdB
true
2 sIdA || sIdC
false
…
condE evaluator
(3)
update
condE
Service Layer
subscribe()
getStatus()
condE
notify()
Application
図 5 メタセンサの構造
15
1. ユーザはまず，メタセンサに対し複数のセンサをまたがる条件文を通常の
センサと同様に subscribe() メソッドを呼び出すことで登録する．
2. メタセンサは，登録された条件文を解析器 (divider) によって単一の条件文
の組に分割し，それぞれの単体センサ (図 5 における Human Detect Sensor，
Brightness Sensor) に対して条件文を登録する．
3. 単体のセンサがそれぞれセンサデバイスから得られたセンサ値を監視し，登
録された条件文の真偽値を判定する．
4. 条件文の真偽値が変化すれば，単体センサからメタセンサに対して notif y()
メソッドを呼び出すことにより通知 (notify) を行う．
5. メタセンサは，notif y() メソッドの呼び出しで送られた単体センサの真偽
値を用いて，複数のセンサに対する条件文を含む論理式 condE を条件の真
偽を判定する condEEvaluator で評価する．
6. condEEvaluator で評価された結果，真偽値が変化すれば，アプリケーショ
ンにその真偽値を notif y() メソッドを呼び出すことにより通知する．
複数のセンサに対する駆動条件を用いたセンサ駆動サービスを構築する場合，
メタセンサを用いない場合であれば，アプリケーションがそれぞれの単体センサ
に条件文を登録し，それぞれの単体センサから得られた条件文 atom(e) の真偽値
からさらに機器を駆動させるための条件文を判定する必要があった．メタセンサ
を用いると，複数のセンサをまたがる論理式 condE の条件判定や，それぞれの単
体センサへの登録をメタセンサが行うため，アプリケーションはメタセンサに対
して単体センサを使う場合と同様に条件文を一度登録するだけでよい．これによ
り，アプリケーションでの条件文 condE の解析と条件判定を行うプログラムを再
開発する必要がなくなるというメリットがある．
16
Sensor
Device
Application
Get current v
Return the v
i
i
Check whether the
atom(e ) changed
Get current v
Return the v
i
i
i
Check whether the
atom(e ) changed
i
図 6 従来のセンサ駆動サービスのシーケンス図
Service
Layer
Application
Subscribe atom(e )
with the subscriber ID
Sensor
Device
i
Get current v
Return the v
i
Return initial status
i
Get current v
Return the v
i
i
Check whether the
atom(e ) changed
Get current v
Return the v
i
i
i
Notify changed status
and the subscriber ID
Check whether the
atom(e ) changed
i
図 7 提案フレームワークのシーケンス図
17
i
degnahc ) e(mo ta
eh t reh tehw kcehC
v eh t nru teR
v tnerruc teG
i
i
i
degnahc ) e(mo ta
eh t reh tehw kcehC
v eh t nru teR
v tnerruc teG
i
i
i
v eh t nru teR
v tnerruc teG
i
i
v eh t nru teR
v tnerruc teG
i
i
i
degnahc ) e(mo ta
eh t reh tehw kcehC
v eh t nru teR
v tnerruc teG
i
i
i
degnahc ) e(mo ta
eh t reh tehw kcehC
i
v eh t nru teR
v tnerruc teG
i
i
degnahc ) e(mo ta
eh t reh tehw kcehC
v eh t nru teR
v tnerruc teG
i
i
i
v eh t nru teR
v tnerruc teG
i
A rosneS
i
DI rebircsbus eh t dna
su ta ts degnahc yfi toN
DI rebircsbus eh t dna
su ta ts degnahc yfi toN
su ta ts lai tini nru teR
)rosneS(
reyaL
ecivreS
degnahc Ednoc
eh t reh tehw kcehC
degnahc Ednoc
eh t reh tehw kcehC
Ednoc
eh t e taulavE
DI rebircsbus eh t dna
su ta ts degnahc yfi toN
su ta ts lai tini nru teR
DI rebircsbus
eh t h t iw
noitacilppA
Ednoc ebircsbuS
)rosneS a teM(
rosneS
reyaL
ateM
ecivreS
krowemarF rosneS ateM
DI rebircsbus eh t h tiw ) e(mo ta hcae ebircsbuS
eciveD
rosneS
su ta ts lai tini nru teR
)rosneS(
reyaL
ecivreS
degnahc ) e(mo ta
eh t reh tehw kcehC
eciveD
rosneS
B rosneS
図 8 メタセンサのシーケンス図
18
3.5 フレームワークの動作
従来のセンサのシーケンス図 [14] を図 6 に，サービスレイヤを用いた提案フ
レームワークにおけるセンサのシーケンス図を図 7 に，メタセンサを用いたセン
サのシーケンス図を図 8 に示す．
図 6 で示す従来のセンサでは，ネットワークを介して通信が行われるアプリケー
ションとセンサ間で頻繁にメッセージ交換が行われている．開発者が決めたセン
サ値取得の間隔ごとに必ず通信が発生してしまう．またアプリケーションは，セ
ンサ値 vi ，値変換関数 fi などのセンサ固有の情報も把握しないといけなかった．
図 7 に示す提案フレームワークでは，ネットワークを介して行われる通信は条
件を登録する時，真偽値の変化を返す時の 2 通りだけであり，条件が変化しなけ
れば通信は発生しない．サービスレイヤとセンサデバイス間の通信はネットワー
クを介したものではないため，ネットワークには負荷をかけない．アプリケーショ
ンとサービスレイヤ間は登録した条件式の真偽値が変化したという必要最低限の
通信となっている．
同様に，メタセンサを用いた場合でも，アプリケーションとメタセンサ間，メ
タセンサと単体センサ間で通信が必要最低限となっている．
次に，2.5 節で述べた問題点について考える．
問題 1: センサとアプリケーションの結合が密
センサとアプリケーション間の通信は，条件の登録とその条件文の変化の
通知のみである．アプリケーションはセンサについて次の 3 つの情報のみ
を知っておけばセンサを利用することが出来る．
• センサ si の WSDL
• センサ si のプロパティpi
• プロパティpi の型制約 te
これは，センサ固有のセンサ値 vi や変換関数 fi ，センサ値の型制約 tv を知
らなくても利用できることを意味し，センサとアプリケーション間の結合
が疎になっていることを示している．
19
問題 2: スケーラビリティが低い
スケーラビリティを考慮する上で問題となってくるのが，センサデバイス
やそれを利用するアプリケーションが増加することによるアプリケーショ
ンとネットワークの負荷である．アプリケーションの負荷については，値
変換関数による値変換の処理がセンサのサービスレイヤに委譲しているた
め，アプリケーションでの値変換処理をする必要がない．しかし，サービ
スレイヤでその処理を行わなければならないため，総合的には変化してい
ない．それに対し，ネットワークの負荷については，図 6 でセンサ値を一
定時間おきに取得していた状態から，条件登録時と条件文の真偽値が変化
したときの 2 パターンに減少している．
これらのことから，提案フレームワークは 2.5 節で述べた問題点 1，問題点 2 を
解決する設計になっているといえる．
3.6 実装
前節までで提案したフレームワークを Java 言語で実装し，設計の実現性を確
かめた．実装したフレームワークのクラス図を図 9 に示す．
図 9 において，センサは抽象クラスである AbstractSensor クラスを継承した実
装クラスと ServiceLayer クラスの 2 つからなり，メタセンサも AbstractSensor
クラスを継承した実装クラスとして実装する．
ServiceLayer クラスはどの単体センサ，メタセンサにおいても共通で利用さ
れる subscribe メソッドや subscribe された条件式の解釈・条件判定を行う run
メソッドを持つ．センサで行うべき処理のうち，このような共通機能の部分を
ServiceLayer クラスとしてまとめることで，それらの機能の再開発コストを抑
えることが出来る．
センサデバイスは AbstractSensor クラスの継承クラスとし，実装すべきメソッ
ドを AbstractSensor クラスで定義した．また，センサごとに用意される Sensor ク
ラス (図 9 では，例として SingleSensor クラスで示している) では ServiceLayer
20
AtomicCondition
-operator : string
-value
-currentStatus : bool
+getStatus() : bool
*
1
EnvironmentAttribute
ConditionSet
-name : string
-type : string
-min : float
-max : float
-enum : string[]
+isRange() : bool
-subs_id : int
-listAtomicCondition : AtomicCondition []
-currentStatus : bool
-condDescription : string
+getStatus() : bool
1
1
AbstractSensor
-listProperty : EnvironmentAttribute
指定なし
*
1
11
#getValue() : <
>
-convertValue ()
+getProperty() : EnvironmentAttribute[]
ServiceLayer
-listCondE : ConditionSet []
+getStatus(in subs _id : int) : bool
+subscribe(in condE : string, in WSDL : string) : subs_id : int
-eval() : bool
SingleSensor
MetaSensor
-propertyValue
-listSensor : WSDL string[]
-listSubscribe
#getValue() : bool
-convertValue()
+notify(in subs_id : int) : bool
+addSensor (in WSDL : string) : bool
+deleteSensor (in WSDL : string) : bool
-divideConditionAndSubscribe (in condE : string) : bool
指定なし>
#getValue() : <
-convertValue ()
Application
+notify (in subs_id : int)
図 9 実装した提案フレームワークのクラス図
21
クラスで扱わないセンサ固有の値や処理，すなわちセンサデバイスからの値取得
メソッドや値変換関数 f を実装することとした．
メタセンサは，単一のセンサと同様に ServiceLayer クラスに接続して扱える
ようにするため，AbstractSensor クラスの継承クラスとした．M etaSensor クラ
スでは，あらかじめメタセンサをなすセンサの登録や削除，メタセンサの条件文
を登録するためのメソッド addSubscribe，removeSubscribe 等を追加した．
登録された条件文を保持し，与えられたセンサ値から真偽を判定するクラスと
して ConditionSet クラスを定義した．ServiceLayer クラスの subscribe メソッ
ドにより登録された条件文をパースすることによりインスタンスが生成される．
ConditionSet クラスは複数の AtomicCondition クラスや CondT ree クラスを保
持し，木構造で連結されている．
AbstractSensor クラスは，センサがとりうる環境属性値 e の型制約 te を判定
する EnvironmentAttribute クラスを持ち，アプリケーションからのリクエスト
に応じて EnvironmentAttribute クラスのインスタンスを返す．アプリケーショ
ンはセンサから得られたその EnvironmentAttribute クラスの情報を用いて型制
約 te を知ることができる．
次章では，実装したこのフレームワークを用いて実際にセンサ駆動サービスを
動作させ，アプリケーションやネットワークの負荷を測定した．
22
4. 評価実験
4.1 評価の概要と目的
本章では，従来利用されてきたセンサ駆動アプリケーションに代わり本論文で
提案するセンサ駆動アプリケーションを利用した場合，従来法と比較してアプ
リケーションにおける条件判定の負荷，ネットワークを利用することによるトラ
フィック負荷がどの程度増大・減少するか，2.5 節で提示した問題点をどの程度解
決できているかを実際に提案フレームワークを実装し，動作させることで実験的
に評価する．
4.2 実験環境
提案するフレームワークを実際に実装し，センサとセンサアプリケーション間
の通信がどの程度あるかを実測した．実験環境における実験機の構成を図 10 に
示す．また，実験に利用した実験機環境のハードウェアを表 5 に，実験機のソフ
トウェアの環境を表 6 に，実験で使用した Phidgets の力センサと明るさセンサの
仕様を表 7 に，それらの写真を図 11，図 12 に示した．
図 10 に示すとおり，コンピュータ A に Phidgets の力センサを，コンピュータ
B に明るさセンサを設置した．それぞれのセンサは提案フレームワークにおける
subscribe メソッドや条件判定機構を持ち，各コンピュータで公開されている Web
サービスのインタフェースを経由してそれらのメソッドにアクセスし，条件を登
録することができるようになっている．コンピュータでは 0.1 秒おきにセンサ値
を取得し，変換関数を用いて環境属性値に変換し，登録された条件の真偽を判定
している．センサ値が変化することで条件の真偽値が変化すれば，条件を登録し
たクライアントに対して notify メソッドを呼び出すようになっている．
また図 10 においてコンピュータ C にメタセンサを設置した．このメタセンサ
は力センサと明るさセンサを組み合わせたメタセンサで，2 つのセンサの値を組
み合わせた条件文を登録することができる．
この環境において，2 つの動作パターンで動作遅延を測定した．まず従来法の
23
Force Sensor
Light Sensor
Computer B
Computer A
Computer C
Meta Sensor
Client PC
図 10 実験機の構成
表 5 実験機環境
コンピュータ A
コンピュータ B
CPU
Core Duo U2400 1.06GHz
PentiumIII 750MHz
メモリ
2048MB
512MB
OS
WindowsVista Business
WindowsXP SP2
ネットワーク
100BASE-TX
100BASE-TX
コンピュータ C
クライアント PC
CPU
PentiumM 1GHz
Core Duo U2400 1.06GHz
メモリ
768MB
2048MB
OS
WindowsXP SP1
WindowsVista Business
ネットワーク
100BASE-TX
100BASE-TX
24
表 6 実験環境 (ソフトウェア)
Java
Java 2 Standard Edition (build 1.5.0 11-b03)
Web サーバ
Tomcat 5.5
Web サービスエンジン Axis2[15]
表 7 Phidgets センサの仕様
センサ名
プロパティp
型制約 tv
変換関数 f
力センサ
F orceSensor
int{0, 1000}

 true
e=
 f alse
明るさセンサ
LightSensor
int{0, 1000}
e=v
図 11 Phidgets 力センサ
25
for v ≥ 500
for v < 500
図 12 Phidgets ライトセンサ
動作パターンとして，クライアント PC で動作するクライアントアプリケーショ
ンからセンサの Web サービスに対して一定時間おきにセンサ値を取得し，クラ
イアントアプリケーションにおいてセンサ値を環境属性値に変換し，条件判定を
行い，機器を駆動させた．また，提案法の動作パターンとして，条件文をメタセ
ンサに登録することで，メタセンサが必要な個別の条件文を力センサと明るさセ
ンサに対して登録し，条件の変化を通知してもらうこととした．
4.3 実験手順
4.2 節で示す実験環境において，次の実験手順で実験を行った．
手順 1. タイムスタンプ出力のためのプログラムコードの挿入
まず，実装したフレームワーク中で時間を測定したいポイントに，現在の
時間を出力するコードを挿入した．タイムスタンプ出力のためのコードは，
Java 言語の java.util.logging パッケージを用い，ミリ秒単位で出力するこ
ととした．出力される時間の誤差はコンピュータに搭載されているオペレー
ティングシステムの時刻精度に依存し，今回実験で用いている Windows シ
リーズではおよそ 10 ミリ秒である．
手順 2. コンピュータの時刻の同期
26
コンピュータ間のネットワーク負荷を測定するため，各コンピュータの時
刻を出来る限り同一にしておく必要がある．まず，それぞれのコンピュータ
に対して，同じネットワークに設置してある Network Time Protocol(NTP)
サーバに接続し，コンピュータの時間を同期させる NTP[16] を用いて時刻
を同期させた．各コンピュータの時間のずれは，30 ミリ秒以内となった．手
順 1 で述べたオペレーティングシステムの時間誤差とあわせて，本実験に
おける時間誤差は 40 ミリ秒程度である．
手順 3. 条件の登録
次に，クライアントアプリケーションから力センサと明るさセンサの二つ
のセンサの値を条件式に持つ以下のような条件式をメタセンサに対して登
録した．
F orceSensor eq f alse && LightSensor < 50 then
:: http : //163.221.172.122 : 8080/axis2/services/SAClientService/ :: notif y
(11)
条件式 (11) では，F orceSensor が押されていない状態，かつ LightSensor
で取得した明るさが 50 ルクス未満となったとき，条件を登録したクライア
ントアプリケーションに対して notif y メソッドを呼び出すといったことを
表している．
従来手法では，上記の条件文に該当する条件判定のプログラム (図 13) を
Java 言語で実装し，動作させた．(なお，分かりやすさのため，一部プログ
ラムを書き換えている．)
手順 4. センサの監視と条件判定・通知
条件が登録されると，それぞれのセンサは自動的にセンサの値を監視し，取
得したセンサの環境属性値 e を用いて登録されている条件式を判定する．状
態が偽から真に変化すれば true を，真から偽に変化すれば f alse を notif y
メソッドを呼び出すことでクライアントアプリケーションに通知する．
27
if(ForceSensor.status == false &&
LightSensor.currentValue < 50) {
System.out.println("invoke notify method.");
}
図 13 実験で使用した条件文の Java 言語による実装
従来手法では，それぞれのセンサの getV alue メソッドを 100 ミリ秒おきに
呼び出し，現在のセンサ値を取得し，変換関数を用いて環境属性値に変換
し，図 13 のコードで条件判定した．
これらの動作のいくつかに時間を測定するポイントを設け，タイムスタン
プを記録していく．この試行を 10 回繰り返し，10 回の平均を結果として用
いる．
これらの手順に加え，センサ値の変化により notif y メッセージを送信させるた
め，表 8 に示す順番でセンサ周辺の環境を変化させた．力センサにおいて，力セン
サの状態が of f であるとは，力センサのボタンを押していない状態，on は押して
いる状態，明るさセンサにおいて，bright はセンサを手で覆わず明るい状態，dark
はセンサを手で覆い，暗い状態を示す．P hase0 はメタセンサからの subscribe が
来た直後の状態，P hase1 は力センサを押した状態，P hase2 はそれに加え，明る
さセンサを暗くした状態といったそれぞれのセンサの状態を表す．
この手順に従って，提案フレームワークによるセンサを用いた場合と，従来型
のセンサを用いた場合の 2 通りで動作させ，それらを比較することでアプリケー
ションとネットワークの負荷を測定した．
4.4 結果
従来法における実験の測定結果を表 9 に，提案法の測定結果を表 11 に示す．
なお，表 9 において，従来法における値取得とその判定処理はセンサ駆動サー
ビスの駆動条件の結果によらず毎回行われるため，P hase による区別を行ってい
28
表 8 実験フェーズ
力センサ
力センサの
明るさセンサ
明るさセンサの
メタセンサの
の状態
条件文の真偽
の状態
条件文の真偽
条件文の真偽
Phase 0
off
true
bright
false
false
Phase 1
on
false
bright
false
false
Phase 2
on
false
dark
true
false
Phase 3
off
true
dark
true
true
Phase 4
off
true
bright
false
false
表 9 結果 (従来法)
no.
1
2
3
4
5
6
7
測定場所
測定要素
クライアント→力センサ
通信
力センサ
処理
力センサ→クライアント
通信
クライアント
処理
クライアント→明るさセンサ
通信
明るさセンサ
処理
明るさセンサ→クライアント
通信
平均時間 (msec)
3605.00
137.31
614.00
0.00
5341.00
617.17
−959.00
ない．また，表 11 における測定要素の項目で，
「処理」は同一 PC 内での条件判
定などの処理を指し，
「通信」は PC から PC への Web サービス呼び出しを含む通
信速度を測定したことを示している．
各表において測定した時間に負の値が含まれる．これは，測定に利用したコン
ピュータ間の時間のずれのために発生する．この時間のずれを排除するため，コ
ンピュータ間の通信における行きと帰りの合計をとり，その結果を表 10，表 12
に示す．
29
表 10 従来法における速度の平均時間
no.
測定場所
測定要素
1
2
3
4
力センサ
処理
明るさセンサ
処理
クライアント⇔力センサ (往復)
通信
クライアント⇔明るさセンサ (往復)
通信
平均時間 (msec)
137.31
617.17
4219.00
4382.00
5. 考察
5.1 フレームワークの特徴
従来法と比較した提案フレームワークの動作を，以下の観点から考察を行った．
センサとアプリケーションの疎結合性
まず，2.5 節で述べた問題点について考察する．問題点 1 として，センサと
アプリケーションの密結合の問題があった．従来では，アプリケーションが
センサを扱う場合，センサの詳細な仕様を知っておく必要があった．しか
し，提案フレームワークを用いることで，センサにおけるセンサ値の型制
約や，センサ値を環境属性値に変換する変換関数を知っておく必要がなく
なった．実験で用いた条件式である式 (11) においても，提案フレームワー
クではセンサ固有のセンサ値や変換関数をセンサから通知を受けるアプリ
ケーションに記述していない．このことから，センサとアプリケーション
間で疎結合性が高まったと言える．それにより，実験で使用した Phidgets
の力センサや明るさセンサを別ベンダ製の力センサ，明るさセンサに置き
換えても，アプリケーションにはほとんど変更を加えずに同様に利用する
ことができる．
上記の点から，2.5 節におけるセンサ駆動サービスの問題点 1 は解決できた
といえる．
スケーラビリティ
30
表 11 結果 (提案法)
no.
フェーズ
測定場所
測定要素
平均時間 (msec)
1
2
3
4
5
6
7
8
9
10
subscribe
クライアント→メタセンサ
通信
メタセンサ
処理
メタセンサ→力センサ
通信
メタセンサ→明るさセンサ
通信
力センサ
処理
明るさセンサ
処理
力センサ→メタセンサ
通信
明るさセンサ→メタセンサ
通信
メタセンサ
処理
メタセンサ→クライアント
通信
4896.00
89.23
397.60
938.00
81.00
257.00
73.70
283.80
9.36
−3.70
11
12
13
Phase1
力センサ→メタセンサ
通信
メタセンサ
処理
メタセンサ→力センサ
通信
14
15
16
Phase2
力センサ→メタセンサ
通信
メタセンサ
処理
メタセンサ→力センサ
通信
17
18
19
Phase3
明るさセンサ→メタセンサ
通信
メタセンサ
処理
メタセンサ→明るさセンサ
通信
20
21
22
23
24
Phase4
力センサ→メタセンサ
通信
メタセンサ
処理
メタセンサ→クライアント
通信
クライアント→メタセンサ
通信
メタセンサ→力センサ
通信
25
26
27
28
29
Phase5
明るさセンサ→メタセンサ
通信
メタセンサ
処理
メタセンサ→クライアント
通信
クライアント→メタセンサ
通信
メタセンサ→明るさセンサ
通信
31
52.40
5.73
35.70
61.90
5.38
−9.70
604.00
2.74
872.00
60.40
69.14
−4.00
38.00
−10.20
960.50
44.43
−4.40
36.40
−8.10
表 12 提案法における速度の平均時間
no.
フェーズ
測定場所
測定要素
平均時間 (msec)
1
2
3
4
5
6
条件登録時
クライアント⇔メタセンサ
通信
メタセンサ⇔力センサ
通信
メタセンサ⇔明るさセンサ
通信
メタセンサ (合計)
処理
力センサ
処理
明るさセンサ
処理
4892.30
471.30
1221.80
98.59
81.00
257.00
7
8
9
監視時
力センサ⇔メタセンサ
通信
明るさセンサ⇔メタセンサ
通信
メタセンサ⇔クライアント
通信
63.83
1214.20
33.00
10
監視時 (notify なし)
メタセンサ
処理
4.46
11
監視時 (notify あり)
メタセンサ
処理
56.79
次に，問題点 2 であるスケーラビリティの問題を考える．実験ではセンサ
を 2 個，メタセンサを 1 個使用したが，さらにセンサ数を増加させた場合，
従来法では表 10 における No.1∼No.4 の値を合計した処理時間が毎センサ
アクセスごとにかかってしまうことに加え，センサアクセスは 100 ミリ秒
おきなどの短い時間おきに通信が発生する．そのため，同一ネットワーク
上で利用できるセンサの数には限界がある．一方で，提案手法を用いた場
合，条件登録時に表 12 における No.1∼No.6 の処理時間の合計がかかり，そ
の後は No.7,8,10 を合計した処理時間，状態によっては No.7,8,9,11 を合計
した処理時間がかかる．いずれの場合においても，従来法と比較してかか
る時間が少ない．さらに，提案法では従来法のように絶えずネットワーク
を経由して値取得のためのアクセスを行うのではなく，登録した条件文の
真偽値が変化したときのみ通信を行うため，同一ネットワークに接続され
ているセンサ数は従来法と比較して増やすことができる．また，センサ値
は絶えず変化するが，登録されているセンサ駆動の条件文は頻繁に状態が
変化することは少ないため (例えば，今回の実験においては，1 回の実験あ
たりセンサ値は数百回変化したが，条件文の真偽値の変化による notif y メ
32
ソッド呼び出しの通知は 5 回であった)，さらに通信コストは抑えられる．
これらのことから，センサ駆動サービスの問題点 2 が解決できたといえる．
ネットワークの負荷
従来法では，クライアントアプリケーションとセンサ間の通信が，表 10 よ
り力センサの場合で約 140 ミリ秒，明るさセンサの場合で約 620 ミリ秒あっ
た．提案法では，表 12 より条件登録時に力センサで約 80 ミリ秒，明るさ
センサで約 260 ミリ秒，センサ監視時に力センサで約 60 ミリ秒，明るさセ
ンサで約 1210 ミリ秒であった．
従来法では，一定時間おきにネットワークを介してセンサ値を得るための
通信が行われるため，上記の負荷が常にかかってしまう．一方で，提案法
を用いた場合では，条件が変化したときのみ，上記の負荷がかかる．また，
その負荷も従来法におけるセンサ値を得るための通信における負荷程度で
あるため，大きな負担とはならないと言える．
このようなネットワーク負荷の減少は，インターネットを経由したセンサ
の状態を監視したい場合において効果を発揮する．アプリケーションがイ
ンターネットを経由してセンサの情報を得たい場合，従来の方法ではトラ
フィック量が多くなりすぎるため，利用できなかった．しかし，提案手法を
用いることで，ネットワークのトラフィック量が削減され，利用できるよう
になる．それにより，インターネット上にさまざまなセンサを公開し，ユー
ザは利用したいセンサを自由に利用するといったことも実現可能となる．
5.2 フレームワークの限界
センサ駆動サービスにおいてセンサやそれを利用するアプリケーションが増加
した場合に発生する問題点を，提案フレームワークを用いることで解決できた．
しかし，条件判定処理のセンサへの委譲によって，アプリケーション側での処理
は減少するが，逆にセンサでの処理量が増加してしまうといった別の問題が発生
する．すなわち，センサでは登録された条件文を解釈し，その条件文をメモリに
33
保存し，一定時間おきに取得したセンサ値を用いてそれらの条件文の真偽値を判
定しなければならない．そのため，従来よりもセンサに持たせるハードウェアの
性能が求められる．しかし，センサ数やセンサを利用するアプリケーション数が
多い場合には，提案フレームワークを用いなければネットワークが疲弊してしま
い，センサネットワークを複数設置しなければ運用することが出来なくなる．そ
の点を考慮すると，センサ数やアプリケーション数が多い場合，それらが増加す
ればするほど提案手法を用いることでコストの問題は極小となる．
また，提案フレームワークはリアルタイムにセンサの値を監視したいようなア
プリケーションには用いることができない．なぜなら，利用される状況として，
センサの値が一定の条件を満たしたときに何らかのアクションを行うという利用
形態を想定しており，アプリケーションには条件の真偽値が変化したときしか現
在の値を知る方法がないからである．このような用途のアプリケーションのため
に，従来のセンサ値を一定時間おきに取得するためのメソッド getStatus を互換
性のために提供している．そのため，一定時間ごとにセンサに値を取得しに行く
という従来の方式を併用することができる．しかし，その方法をとった場合，リ
アルタイム性を求めるアプリケーションにおいては 2.5 節で述べた問題点のいず
れも解決できなくなる．
5.3 先行研究との比較
幸島ら [17] は，複数の異なるセンサ情報を統一的に管理し，高次のサービス
と連携させる機能を提供するミドルウェアである SENSORD を提案している．
SENSORD では，センサデバイスにセンササーバを付属させ，センサデバイスか
ら得られたデータをネットワークを介して SENSORD ミドルウェアに蓄積する．
ユーザは SENSORD スクリプトを用いてルールを記述しておき，蓄積されたセン
サデータに対して評価を行い，ルールが適合する場合に対応するサービスを起動
する．
本論文における提案フレームワークと SENSORD との違いは，ユーザが登録
したセンサ駆動サービスのルールをセンサが評価するか，ミドルウェアでセンサ
データを蓄積しておき，SENSORD アプリケーションで評価するかの違いである．
34
SENSORD では，ネットワークを介して SENSORD アプリケーションにセンサ
データがそのまま保存される．しかし，センサデータがネットワークを流れるた
め，2.5 節で提示したスケーラビリティの問題の解決にはなっていない．ただし，
SENSORD ではセンサデータを蓄積しているため，過去のデータを利用するよう
なスクリプトを記述できることが SENSORD のアドバンテージとなっていると考
えられる．
35
6. おわりに
本論文では，センサの情報を元に機器を駆動させるセンサ駆動アプリケーショ
ンにおいて，スケーラビリティを考慮したときに発生する問題点を解決したフレー
ムワークを提案した．
従来のセンサ駆動サービスでは，センサを利用するアプリケーションがセンサ
を利用する際に，センサがとる値の意味やその値を知っていなければ利用できず，
センサとアプリケーションの結合が密であるという問題があった．提案したフレー
ムワークでは，センサに標準的なインタフェースをもたせ，センサ固有の値や処
理をセンサ側で処理させることで，どのセンサを利用する場合でも共通の方法で
利用することが出来るようになった．
また，センサ数を増加させることによるスケーラビリティの問題に対しては，
センサ駆動サービスの条件判定処理をアプリケーションからセンサ側に委譲する
ことにより，アプリケーションは登録した条件の真偽値の変化のみを通知しても
らうため，アプリケーションやネットワークにかかる負荷を軽減し，スケーラビ
リティを向上させた．
この提案フレームワークを実装し，アプリケーションとネットワークの負荷を
測定する実験を行った．実験では，1 回あたりのネットワークの負荷は同程度な
がらも，その通信回数が大きく減少させることができたため，総量を大幅に減少
させることができた．これにより，従来法よりも上記 2 点の問題点に対して優位
性があることを確認した．
36
謝辞
本研究を進めるにあたり，多くの方々に御指導，御支援を賜りました．心から
深く感謝申し上げます．
奈良先端科学技術大学院大学 情報科学研究科 松本 健一 教授には，2 年間にわ
たって研究する場や機会を賜りました．また，本研究を進めるにあたっては，多
大な御指導や御配慮を頂きました．心より深く感謝申し上げます．
奈良先端科学技術大学院大学 情報科学研究科 伊藤 実 教授には，副指導教官
を担当して頂き，研究の内容について鋭い御指摘や御助言を頂きました．心より
深く感謝申し上げます．
奈良先端科学技術大学院大学 情報科学研究科 門田 暁人 准教授には，研究全
般を通して研究の地を固めていくことについて，多大な御指導，御助言を頂きま
した．心より深く感謝申し上げます．
神戸大学 大学院工学研究科 中村 匡秀 准教授には，研究の根幹に関わる部分
から研究の進め方について多大な御指導，御助言を頂きました．また，研究論文
の書き方やプレゼンテーションの作法においても，有益な数多くの知識，技術に
ついて全面的に御指導頂きました．心より深く感謝申し上げます．
奈良先端科学技術大学院大学 情報科学研究科 飯田 元 教授には，本研究を進
めるにあたって鋭い御指摘を頂きました．心より深く感謝申し上げます．
奈良先端科学技術大学院大学 情報科学研究科 大平 雅雄 助教には，ソシオメ
トリクス班にて複雑な事象を組み立てていくという論理的なものの考え方につい
て丁寧な御指導を頂きました．心より深く感謝申し上げます．
奈良先端科学技術大学院大学 情報科学研究科 川口 真司 助教には，共起関係
分析班にて鋭いご指摘や，研究の進め方について御指導を頂きました．心より深
く感謝申し上げます．
神戸大学 大学院工学研究科 井垣 宏 助教には，本フレームワークの実装にお
ける技術的な御支援にはじまり，研究の内容や進め方について鋭い御指摘，御指
導を頂きました．また，論文の書き方やプレゼンテーションの作成においても有
益な御助言，御助力を頂きました．心より深く感謝申し上げます．
奈良先端科学技術大学院大学 情報科学研究科 森崎 修司 助教には，本研究を
37
進めるにあたって鋭い御指摘を頂きました．心より深く感謝申し上げます．
奈良先端科学技術大学院大学 情報科学研究科 博士後期課程 山内 寛己 氏には，
本論文の作成にあたって多大な御指導，御指摘を頂きました．心より深く感謝申
し上げます．
奈良先端科学技術大学院大学 情報科学研究科 Web サービス班の皆様には，週
次のミーティングにおいてさまざまな御意見や御助言を頂きました．心より深く
感謝申し上げます．
奈良先端科学技術大学院大学 情報科学研究科 ソフトウェア工学講座 およびソ
フトウェア設計学講座の皆様には，日頃の研究生活においてさまざまな御助言を
頂き，心地よい研究環境を与えて頂きました．心より深く感謝申し上げます．
最後に，2 年間の大学院での研究生活において，陰ながら支えてくれた祖母，
父，母，妹に心より深く感謝いたします．
38
参考文献
[1] H. Igaki, M. Nakamura, and K.-I. Matsumoto. Design and Evaluation of the
Home Network Systems Using the Service Oriented Architecture. In Proceedings of the International Conference on E-Business and Telecommunication
Networks(ICETE’04), Vol. 1, pp. 62–69, August 2004.
[2] M. Nakamura, A. Tanaka, H. Igaki, H. Tamada, and K.-I. Matsumoto.
Adapting Legacy Home Appliances to Home Network Systems Using Web
Services. In IEEE International Conference on Web Services (ICWS’06),
pp. 849–858, September 2006.
[3] 田中章弘, 中村匡秀, 井垣宏, 松本健一. Web サービスを用いた従来家電の
ホームネットワークへの適応. 電子情報通信学会技術研究報告. Vol. 105, No.
628, pp. 067–072, March 2006.
[4] Matsushita
Electric
Works
Ltd.
Katteni
switch.
http://biz.national.jp/Ebox/katte sw/.
[5] Daikin Industries Ltd. Air conditioner. http://www.daikin.com/global ac/.
[6] Nabtesco
Corp.
Automatic
entrance
system.
http://nabco.nabtesco.com/english/door index.asp.
[7] TOTO USA Inc. Sensor Faucet. http://www.totousa.com/prodcatalog.asp?cid=54.
[8] J. Nehmer, M. Becker, A. Karshmer, and R. Lamm. Living Assistance Systems: An Ambient Intelligence Approach. In Proceedings of the 28th International Conference on Software Engineering(ICSE’06), pp. 43–50, 2006.
[9] World
Wide
Web
Consortium.
http://www.w3.org/2002/ws/.
39
Web
Services
Activity.
[10] G. Mühl. Generic Constraints for Content-Based Publish/Subscribe. In
Proceedings of the 9th Internationall Conference on Cooperative Information
Systems(CooplS’01), pp. 211–225, 2001.
[11] S. Greenberg and C. Fitchett. Phidgets: Easy Development of Physical
Interfaces through Physical Widgets. In Proceedings of the 14th Annual
ACM Symposium on User Interface Software and Technology(UIST’01), pp.
209–218, 2001.
[12] Network Working Group.
Augmented BNF for Syntax Specifications:
ABNF. http://www.ietf.org/rfc/rfc4234.txt.
[13] World Wide Web Consortium. Web Services Description Language (WSDL)
1.1. http://www.w3.org/TR/wsdl.
[14] Object Management Group Inc. Unified Modeling Language (UML), version
2.1.1. http://www.omg.org/technology/documents/formal/uml.htm.
[15] Apache Software Foundation. Apache Axis2. http://ws.apache.org/axis2/.
[16] Network Working Group. RFC:1305 Network Time Protocol(Version 3).
http://www.ietf.org/rfc/rfc1305.txt.
[17] A. Sashima, Y. Inoue, and K. Kurumatani. Spatio-Temporal Sensor Data
Management for Context-Aware Services: Designing Sensor-Event Driven
Service Coordination Middleware. In Proceedings of the 1st International
Workshop on Advanced Data Processing in Ubiquitous Computing (ADPUC’06), 2006.
40
付録
A. BNF 記法によるルール記述
ConditionSetExpression::
ConditionalOrExpression "then" AtomicAction ( ’,’ AtomicAction )*
ConditionalOrExpression::
ConditionalAndExpression ( "||" ConditionalAndExpression )*
ConditionalAndExpression::
AtomicConditionExpression ( "&&" AtomicConditionExpression )*
AtomicConditionExpression::
AtomicCondition
AtomicConditionWithNot
AtomicConditionWithNot::
"!" AtomicCondition
AtomicCondition::
SensorName Operator CompareValue
SensorName::
id
Operator::
"<"
">"
"<="
41
">="
"=="
"!="
"eq"
CompareValue::
id
TrueFalse
TrueFalse::
"true"
"false"
B. センサ駆動アプリケーションのメソッドとその引数
センサ駆動サービスを構成する各モジュールが実装すべきメソッドと，とるべ
き引数をまとめた．なお，実装は Java 言語で行ったため，一部 Java 言語に依存
する制約が含まれる．
B.1 クライアントアプリケーション
クライアントアプリケーションとは，センサに対して条件文を登録し，条件が
変化したときに notif y を受けるアプリケーションである．以下に，メソッド一覧
とその引数を示す．
notify
センサ駆動サービスに対して登録した条件文の真偽値が変化したときに送
られる通知は，このメソッド呼び出すことで行われる．
int sensorId センサ固有の ID
42
int subscribeId 登録時に戻り値として得られる登録条件 ID
boolean status 最新のステータス
B.2 サービスレイヤ
サービスレイヤとは，センサ駆動サービスにおけるセンサの共通機能を実装し
たクラスである．以下のメソッドを持つ．
ServiceLayer
ServiceLayer クラスのコンストラクタである．
int sensorType 単体センサモードとして動作するか，メタセンサとして
動作するかを切り替えるオプションである．3.6 節で示した実装では，
1 を指定すると単体センサ，2 を指定するとメタセンサとして動作する．
AbstractSensor sensor センサデバイスから値を取得するセンサクラス
のインスタンス
getStatus
現在の登録条件の真偽値を返す．
int subscribeId 登録条件 ID
subscribe
通知条件を登録する．
String condE 条件文
run
センサデバイスからセンサ値を取得し，環境属性地に変換し，条件文の真
偽値を判定し，真偽値が変化すれば通知を行うといった，一連のセンサ監
視動作を行う．一定時間おきにこのメソッドを呼び出すことで，センサ値
を監視し，通知を行うことができる．引数はとらない．
43
notifyClient
条件文の真偽値が変化したときに，クライアントアプリケーションに通知
を行うメソッドである．本メソッドのスコープはクラス内からのアクセス
のみである．
ConditionSet cs 条件文が保存されているオブジェクト
getValue
センサ値を得るメソッドである．提案フレームワークのインタフェースの
みでなく，従来のセンサとしても利用できるよう，本メソッドを残してい
る．引数はとらない．
B.3 センサ
subscribe
条件を登録するメソッドである．
String condE 登録する条件文
getProperty
センサの型制約情報を示す EnvironmentAttribute クラスのオブジェクト
を返す．引数はとらない．
B.4 メタセンサ
メタセンサは，AbstractSensor クラスを継承したクラスで実装する．インタ
フェース自体は，単体センサのものとクライアントアプリケーションのものを両
方共存させたものとなっている．
44
B.5 ConditionSet
ConditionSet クラスは，登録された条件文が木構造で保持されたオブジェクト
である．
getStatus
条件文の現在のステータスを返す．引数はとらない．
updateStatus
引数に最新のセンサ値を与えることで，保持している条件文の真偽値を再
度判定し，その真偽値を返す．
Obejct o 最新のセンサ値．int であるか String であるかはセンサの型制
約の違いによるので，ここでは Object 型を用いている．
B.6 AtomicCondition
ConditionSet と同様のインタフェースを持つ．それに加え，以下のコンストラ
クタを持つ．
AtomicCondition
AtomicCondition クラスのコンストラクタである．
int sensorType センサのタイプ
AbstractSensor sensor センサオブジェクト
int subscribeId 登録 ID
String property プロパティ名
String operator 演算子
Object value 比較する値
45