2008年度森基金 活動報告

研究課題名：センサノードにおけるアプリケーション動作時間保証

氏名：森 雅智

所属：政策・メディア研究科

要旨

近年，携帯電話やセンサノードといった，バッテリ駆動型で複数のアプリケーションが

同時に動作するマイクロユビキタスノードに関する研究が活発である．マイクロユビキタス

ノードは急激な進化を遂げており，一台のノードに搭載されるアプリケーションの種類は

年々増加している．例えば，初期の携帯電話は電話機能だけだったものが，今日ではメール

送受信機能や音楽再生，TV 視聴機能等が搭載されている．

一方で，マイクロユビキタスノードの電源管理は複雑化している．第一に，複数アプリ

ケーションが同時に動作する環境では，単機能のデジタルカメラなどと違いバッテリ切れ

の予測が困難である．それぞれのアプリケーションは異なるデバイスを異なる使用頻度で

使用するため，消費電力はアプリケーションや利用者の使用頻度に応じて異なる．その

ため単純に残り動作時間を予測することができず，利用者の意図しないタイミングで

バッテリが切れてしまうという問題が発生する．第二にマイクロユビキタスノードでは

複数のアプリケーションが一つのバッテリ資源を共有するため，利用者にとって優先度

の低いアプリケーションが，より優先度の高いアプリケーションの動作を抑制してしま

うという問題がある．こうした問題は，ゲームなどのさほど重要でないアプリケーション

では大きな問題にならないが，人命に関わるような安全性を確保するためのアプリケーシ

ョンにとっては致命的な問題である．こうした問題により，現在のマイクロユビキタス

ノードは高可用性を要求される分野に適用するのは難しい．

本研究ではこうした複数のアプリケーションが混在するマイクロユビキタスノード環境

において，特定アプリケーションの動作時間を保証するシステムを提案し，実装，評価

を行った．そして動作保証を実現する上で，アプリケーション別の消費電力測定機構と

その収集データを基にアプリケーションを制御する機構を作成した．本システムにより，

重要なアプリケーションの動作時間を保証することができるようになり，従来マイクロ

ユビキタスノードが提供することのできなかった品質保証型のサービスが

実現可能となる．

システム設計

想定環境

本システムはマイクロユビキタスノードでの動作を前提としている．マイクロユビキタス

ノードとは，以下の条件を満たしたノードのことである．

• 人が容易に持ち歩けるか，部屋や公共空間などに埋め込める程度に小型なこと

• バッテリ駆動であること．但し充電可能なものも含む

• 一台のノード上で複数のアプリケーションが動作すること

次に，pSurvive 要求として，マイクロユビキタスノードの中でも次の機能を有している必

要がある．

1. ノード全体のバッテリ残量が取得可能であること

2. 各デバイスがデバイスドライバのような共通 API を通して行われていること

3. 各デバイスの使用量を測定するために，最低でも各デバイスの ON/OFF 状態が分かること

一番目について，pSurvive はノードの残バッテリ量を元に消費電力量の測定を行う．

そのため，ソフトウェア側が全体のバッテリ残量を知る方法が不可欠である．また，ここで

取得できるバッテリ残量は 0，25，50，75，100 ％しか状態が無いような大雑把ものでは

なく，値がある程度細かく取れることを前提とする．この値の細かさは，消費電力量測定

の精度に関わるので重要な項目である．しかし，この機能は既存のほとんどのマイクロユ

ビキタスノードが既に持っている機能である．例えば，NTT ドコモの端末で動作する Java

　ライブラリ Doja では，バッテリ残量を取得するための PhoneSystemクラスが定義

されているし，Windows Mobile においても GetSystemPowerStatusExAPI を呼び出すことで

バッテリ残量が取得可能である．よって，この前提条件は実現上さほど問題にならないと考

えられる．

次に，二番目と三番目は実装上の問題である．消費電力量測定の際，各デバイス別の使用時間を

計測するため，デバイスの使用状況をモニタリングする必要がある．そのため，デバイスドラ

イバのような共通 API にモニタリングのための機構を実装するのが望ましい．また，無線やセ

ンサなどの電源を切ることの可能なデバイスについては，そのデバイスの使用量を計測するた

めにデバイスの動作状態を取得できる必要がある．この機能についても，既に多くのマイクロ

ユビキタスノードが実装済みである．

なぜなら，マイクロユビキタスノードの省電力化のための試みは既に長く続けられており，消

費電力削減のために使っていないデバイスの電源を落としたり，短い時間であってもアイドル

時にスリープさせるといった機能が搭載されている．そのため，システム側にも必ずデバイ

スを制御するためのインターフェースが存在するので，その部分にモニタリングのための機

能を搭載すればよい．よって，これらの前提条件もシステムのハードウェアに大きな変更を

強いるものではなく，現状のマイクロユビキタスノードにも十分に対応可能である．

以上が本システムが動作するための必須環境となる．

システム構成

pSurviveの全体構成は以下の図の通りである．

pSurviveは図に示したとおり，消費電力計測・予測機構と動作時間保証機構によって構成される．

アプリケーション別消費電力計測・予測機構

本節では pSurvive の根幹であるアプリケーション別消費電力計測・予測機構の設計

について解説する．まず pSurvive が用いる消費電力量モデルを示し，その後各変数を

どのようにして計測し定義するかを示す．

消費電力量モデル

まず始めに，マイクロユビキタスノードにおいてデバイスの消費電力がどの程度大

きいのかを調べるために事前実験を行った．実験環境は後述するものと同じマ

イクロユビキタスノード環境で，各デバイスの使用状態別に消費電力を測定したもの

が以下の図である．縦軸はバッテリ残量を満充電時を 100%とした電圧値の変化である．

0 の状態は実際に電圧が 0 になったのではなく，デバイスの動作に必要な電圧が得られ

なくなり，デバイスの電源が切れてしまったことを表している．

この実験ではデバイスの使用電力に着目するために，システム上では特にアプリケー

ションは起動させず，ノードを起動させる最低限の環境で実験を行っている．それぞ

れ，Bluetooth とセンサデバイスの二種類のデバイスについて，電源 ON と電源 OFF

にした場合の動作時間を計測した．結果，各デバイスの電源を入れた状態と入れてい

ない状態では明らかに動作時間が異なることが分かった．特に，両方のデバイスの電

源を ON にした場合では動作時間に倍以上開きがある．なお，バッテリ残量の曲線が

800 を下回った辺りで急激に低下していることがわかるが，これは使用しているリチ

ウムイオンバッテリの特性であると考えられる．この実験により，マイクロユビキタ

スノードにおいては各デバイスの消費電力がノード全体の消費電力の大きな部分を占

めていることが分かる．

実験結果を踏まえてpSurvive では，アプリケーションの使用電力量を各アプリケー

ション，各デバイス別に計測し，それらの電力の和を全体の消費電力として扱う．ま

ず，ノードがn 個のデバイスを持っていると考える．このデバイスとは，CPU やメ

モリ，ネットワークやセンサといった電力を消費するハードウェアを指し，各デバイ

スをd1, d2, d3, ..., dn とする．そして，各デバイスの単位使用量あたりの消費電力をc

[mW/units] とし，c1, c2, c3, ..., cn とする．これは例えば液晶ディスプレイを1 分間動

作させるのに必要な電力といったものに対応する．この単位使用量の単位unit とは，

デバイスによって定義が異なる．例えば液晶ディスプレイといったデバイスでは使用

時間が電力消費量の指標になるが，センサデバイスではセンシングする回数で使用電

力が決まるため，時間ではなくセンシング回数となる．

この時，デバイスの消費電力の合計E はデバイスの使用量をt [units] とすると，E =

ct [mW] で表される．そのため，各デバイスの使用時間をt1, t2, t3, ..., tn とすると，ノー

ド全体の消費電力量は以下の式で表される

次に，ノード上ではm個のアプリケーションが動作しているとし，p1, p2, p3, ..., pm

で表す．このアプリケーションはアプリケーションに対応している．アプリケーション

は各デバイスを使用するため，アプリケーションの使った各デバイスの消費電力量の

総和がそのアプリケーションの消費電力量であると考えられる．ここで，アプリケー

ションp がデバイスd を使用した使用量を求める関数f(p, d) を定義する．すると，ア

プリケーションp の消費電力Ep は以下の式で表される．

ここで，OS や待機電力を特殊なアプリケーションとして抽象化すると，デバイス全

体の消費電力は各アプリケーションの消費電力の和となる．そこで，これまでの2式から

以下の式がが導き出される．

pSurvive では，この式に従って消費電力を計測する．そのために必要な情報はf(p, d)

及びc，つまりアプリケーションがどのデバイスをどれだけ使っているのかという使用

量と各デバイスの単位使用量あたりの消費電力量である．よって，アプリケーション

別の消費電力計測ではこの二つを計測する．

アプリケーション別消費電力量の計測

まず，アプリケーションのデバイス使用量を計測する方法については，アプリケー

ションはデバイスを使用する際に必ずデバイスドライバを通してアクセスを行うため，

デバイスドライバに機能を追加するという手法を用いる．アプリケーションがデバイ

スを使用する度に使用量を通知するという手法も考えられるが，この場合デバイス上

の全てのアプリケーションに修正の必要があるため，現実的ではない．また，CPU や

メモリについてはデバイスドライバに相当するものが無いため，OS の統計情報などか

らデータを取得する．

次に，デバイスの単位使用量あたりの消費電力量c については前もってキャリブレー

ションを行い，実測値から求めることで対応する．しかし，キャリブレーションで得

た値を静的に利用するのでは動作環境に大きく影響を受けるデバイスについて，実際

の値と大きく異なった値になってしまう恐れがある．例えば，無線LAN を考えた場

合，送信についてはアプリケーションが明示的にデバイスドライバを通して送信を行

うため計測可能であるが，受信の際のOS オーバヘッドを考えた場合，無線LAN チッ

プレベルでは自分宛以外のパケットも受信してしまうため，多くの無線LAN 機器が同

じチャネルで通信している環境の場合，消費電力量がキャリブレーション時と異なる

値になってしまう．こうした問題に対応するために，システムの動作時には静的な値

だけでなく動作環境に応じてc を微調整していく必要がある．

アプリケーション動作時間保証機構

まず始めに，保証対象となるアプリケーションをR1,R2,R3, ...,Rk し，それぞれに

要求された保証時間をT1, T2, T3, ..., Tk とする．すると，アプリケーションR をT だけ

動作するために必要な電力量ER は電力計測の式から以下の式で表される．

よって，全ての保証対象アプリケーションが必要な電力量Erequired は

となる．

実装

実装環境及び動作環境

まず，pSurvive の実装にあたって選定した実装環境及び動作環境を，ハードウェア，

ソフトウェア両方の面から述べる．pSurvive の実装にあたり，必要な要件が四つある．

1. OS に手を加えることが可能で，開発環境が利用できること

2. 実際にマイクロユビキタスノードでの採用例があるか，製品としてすでに販売さ

れていること

3. 本システムの有効性を示すのに十分な評価が取れるだけの機能を有すること

4. 特殊なハードウェアを極力用いず，本システムの汎用性を示せること

1 番目は，アプリケーションの各デバイス使用量モニタリングを OS レベルで実装す

る必要があるので必要である．2 番目の要件については，実際の組み込みシステムで

の採用例があることで，実験結果の信憑性が高まる．3 番目について，細かな評価を

行えるよう，既存のマイクロユビキタスノードと同等かそれ以上の機能を持っている

ことが望ましい．最後の要件は，ハードウェア依存の実装になりがちな組み込みシス

テムの中で，なるべく特定のハードウェアに依存するところを無くし，実験環境以外

のマイクロユビキタスノードでも同じことが言えるということを保証するために必要

である．

本研究においては，こうした動作件を満たすマイクロユビキタスノードとして，Gumstix Ver-

tex XM4-BT及び NUTS センサボードを用いた．

図 1Gumstix Vertex

図 2NUTSセンサボード

アプリケーション別消費電力計測・予測機構

pSurvive の実装では，消費電力計測・予測機構をデバイス毎に実装するモニタリン

グモジュールとデータ集約モジュール，消費電力予測モジュールの三種類に分割した．

その構成を表したものが以下の図である．

それぞれのモジュールは動作レベルでは互いに独立しており，それぞれ別途開発が

可能である．このようにモジュールを分割することで，各部の機能追加や交換を可能

とし，拡張性を高めた．

モニタリングモジュール

モニタリングモジュールは各デバイスに依存するモジュールで，基本的にデバイス

と一対一で対応する．モニタリングモジュールが最低限持つ機能はデバイスの使用量

をカウントする機能で，後述するデータ集約モジュール内のアグリゲータからの要求

に応じてアプリケーション動作中のデバイス使用量をカウントする．デバイス使用量

は CPU なら使用時間，ネットワークであればパケット数といっ

たものが単位となる．モニタリングモジュールはデバイスに対応するものであり，特

にマイクロユビキタスノード自体に依存するものではないので，同じデバイスを使っ

ているノードであればそのまま再利用できる．

具体的な実装方法はデバイスに大きく依存するところがあるが，基本的には Linux

Kernel Module（LKM）を用いて実装することを想定している．LKM を用いて実装す

る理由はデバイスとアプリケーションの対応を取るためである．アプリケーションレ

ベルで実装してしまうと，デバイスの使用量を取得することはできるが，その消費量

がどのアプリケーションに関連付いているかを取得することができない．なぜならば，

モニタリングする時点で既にスケジューラはモニタリングアプリケーションに処理を

渡してしまっているので，実際にデバイスを使用したアプリケーションが限定できな

いからである．

LKM によって実装することでこの問題を解決する．LKM によってデバイスのモニ

タリングを実装することで，コンテキストスイッチ無しにデバイスの使用量を監視す

ることができる．これにより，デバイス使用時にスケジューリングを割り当てられて

いるプロセスが実際にデバイスを使用したアプリケーションとなるため，デバイスと

アプリケーションの対応を取ることができる．

データ集約モジュール

データ集約モジュールは，定期的にモニタリングモジュールに対してデバイスの消費

量を取得するアグリゲータと，取得したデータを時系列で保存する消費電力履歴デー

タで構成される．

アグリゲータは特定の周期でモニタリングモジュールに各アプリケーションのデバ

イス消費量を問い合わせ，消費電力履歴として保存する．モニタリングの周期を短く

することで，よりアプリケーションの詳細なデータが取れるが，その一方でデータ集

約モジュールのオーバヘッドは増加する．しかし，このモニタリング周期の決定には，

バッテリの特性が大きく関わってくる．バッテリ残量の解像度が細かい場合は頻繁な

サンプリングを行うことで詳細なデータを取ることができるが，解像度が低い場合に

頻繁なセンシングを行った場合，連続して同じ値が帰ってきてしまうことが考えられ

る．今回の実装環境であるリチウムイオンバッテリと NUTS センサボードの組み合わ

せにおいては，5 秒∼30 秒程度のセンシング周期では値がほとんど変化しなかったた

め，1 分という周期を採用した．

データ集約モジュールは LKM によるカーネルレベルでの実装ではなく通常のアプ

リケーションとして実装する．その理由はデータ集約モジュール自体も電力を消費す

るため，オーバヘッドを考慮する必要があるからである．LKM による実装を行った場

合，pSurvive の消費電力は OS のオーバヘッドに含まれることになるが，pSurvive の

評価を行う段階で pSurvive を搭載することによるオーバヘッドを測定することができ

ない．また，LKM による実装では利用できる OS の機能が著しく限定されてしまうた

め，消費電力履歴の保存先の変更といった柔軟な対応が難しくなるということも理由

の一つである．

消費電力予測モジュール

消費電力予測モジュールは，アプリケーション別動作時間保証機構からの要求に応

じて，データ集約モジュールが保存した消費電力履歴を元に消費電力予測を行うエス

ティメータと，その予測アルゴリズムで構成される．

消費電力予測は時系列のデータから未来の消費電力を予測するものであるが，必ず

しも全てのアプリケーションに対して一つのアルゴリズムが精度の高い予測結果を返

すとは限らない．例えば，ほぼ一定周期で動作する GPS 位置情報通知のようなアプリ

ケーションであれば，過去のデータからの移動平均といった値が合致すると考えられ

るが，Web ブラウザのような利用者の使用や環境によって電力消費の傾向が大きく変

わるアプリケーションの場合，移動平均だけでは精度の高い予測は難しい．そのため，

消費電力予測モジュールでは複数のアルゴリズムを用意し，アプリケーションに応じ

た予測アルゴリズムを選択可能としておく．これにより，アプリケーション毎に柔軟

な予測を行うことができ，予測精度が高まる．本論文における実装では，2 種類の予測

アルゴリズムを用意する．一つは，消費電力モジュールが直近に計測したのと同じ量

の消費電力を使うという単純なモデルである．このモデルは常に電力消費が一定にな

るようなアプリケーションに最も適合すると考えられる．もう一つは移動平均アルゴ

リズムである．但し，パラメータとして参照する履歴の幅を指定できる様にする．履

歴の幅を短く設定すると，急激な値変動に対して敏感に予測値が変動するため，より

早くアプリケーションの消費電力変動に対応できる一方で，一時的な値変動の影響を

大きく受けてしまう．これは電力を消費するときにある程度長い期間，急激に消費す

るようなアプリケーションが適合するだろう．また，履歴の幅を長く設定することで，

一時的な値変動の影響は小さくなるが，値変動後に変動後の値が続くような場合には

予測値が理想値に近づくのが遅くなる．このアルゴリズムは短い時間に一時的に消費

電力が大きくなる様なアプリケーションが適合するだろう．

消費電力予測モジュールもデータ集約モジュールと同じく通常のアプリケーション

として実装する．その理由もデータ集約モジュールの場合と同じく，拡張性のためで

ある．特に予測アルゴリズムを容易に追加，交換可能とすることは pSurvive の汎用性

を高めるために重要な点である．

アプリケーション別動作時間保証機構

アプリケーション別動作時間保証機構では，アプリケーション別消費電力計測・予

測機構からの予測結果を基に動作保証外アプリケーションの停止処理を行う．本機構

の内部構成は下図の通りである．

バッテリ監視モジュール

バッテリ監視モジュールは，バッテリ残量を定期的に監視し，動作保証モジュール

へ通知する．本モジュールの役割は，動作保証に必要な電力が残っているかを後述の

動作保証モジュールへ伝えることである．バッテリ残量低下時の動作については動作

保証モジュールが行うので，本モジュールはバッテリの監視のみを行う．

本モジュールを分離する意図は，マイクロユビキタスノード毎の違いを吸収するこ

とにある．バッテリ残量を取得する方法は各ノードの種類によって大きく異なるため，

このモジュールを分離しておくことで，pSurvive のノード依存度を下げることができ

る．結果としてバッテリ監視モジュールは各ノード専用に実装する必要があるが，本

機能は単純な機能のみを有するので開発のためのコストは小さい．

本実験環境であるNUTSセンサノードの場合，バッテリ残量はPMUデバイスドライ

バからsys ファイルシステムを通して取得することができる．具体的には/sys/devices

/platform/pxa2xx-i2c.0/i2c-0/ 0-0048/battery/battery voltage に対して通常通りファ

イルとしてアクセスすることで，PMU のレジスタからバッテリ電圧を取得する．こ

の様に，標準のファイルシステムインタフェースからバッテリ残量が取得できるため，

本モジュールはアプリケーションとして実装する．

動作保証モジュール

動作保証モジュールは利用者からの動作保証リクエストを受け取り，どのアプリケー

ションをどれだけの時間，動作保証するのかを保持する．また，前述のアプリケーショ

ン別消費電力計測・予測機構の消費電力予測モジュールに対し，保証対象アプリケー

ションの必要電力量Erequired を問い合わせることで，どれだけの電力量を確保すべき

なのかを取得する．そして，バッテリ残量の低下がバッテリ監視モジュールから通知

された際に残りバッテリ量がErequired に近ければ，動作保証外アプリケーションを終

了させる．また，残りバッテリ量がErequired を下回り，動作保証外アプリケーション

を動作させる余裕が無いときには，起動された動作保証外アプリケーションを終了さ

せる役割も担う．

本実験環境ではOS としてLinux を利用しているため，アプリケーションの停止は

KILL シグナルを送ることで実現する．

実験と評価

センシング周期に関する考察

実験を開始するにあたって，バッテリのセンシングに関する予備実験を行った．実

験ノードにおけるバッテリ残量のセンシングはバッテリの動作電圧として取得するこ

とができるが，この値は生データのため，値に揺らぎが生じることが予想される．そ

のため，揺らぎの幅の分だけの電力消費が行われないうちに次のセンシングが行われ

てしまうと，揺らぎによってバッテリ残量が増加したように見えてしまったり，本来

のバッテリ残量が正常に取得できないことが考えられる．このことを防止するために

は，バッテリ残量のセンシング周期をある程度長い周期で計測することで，揺らぎの

影響を抑えることが必要である．バッテリ残量のセンシングにおいて，どの程度の揺

らぎが生じるのかを実験を行い計測した結果が下図である．この図は実験環境にお

ける最低動作環境においてN 分毎のセンシングを行い，1 分辺りの消費電力量の分散

をプロットしたものである．縦軸は消費電力，横軸がセンシング周期である．

赤線は平均値からの標準偏差の範囲を表しており，赤線の長さが短いほど標準偏差

が小さく，値が収束している．図を見ると分かるように，1 分毎のセンシングでは値

のばらつきが非常に大きく，とうてい信頼できる値が取れているとは言えない．セン

シング周期を長くしていくことで値が収束していき，8 分や16 分程度の周期である程

度値が収束していることが分かった．

このことから，バッテリのセンシングにおいてある時点とある時点を比較する際は，

その時間感覚が狭すぎると信頼の置ける値が取れない事が分かった．そのため今後の

実験においても，実験時間は少なくとも16 分以上の継続的なセンシングを行う必要が

あることが分かった．

デバイスの単位使用量あたり消費電力の計測

消費電力計測機能の評価のために，まずはデバイスの単位使用量あたりの消費電力

を計測する．本実験では，実験環境の動作状態を最低動作環境と，それに加えて CPU，

無線 LAN を使用しているそれぞれの状態についてバッテリ使用量を計測した．この

際，CPU の負荷発生にはモンテカルロ法による円周率計算，無線 LAN の通信には 255

バイトの UDP パケットを送信し続けるというプログラムを使用した．それぞれの動

作状態において，各デバイスの使用状況は以下の様になる．

• 最低動作環境（A）

：最低限の動作環境

• CPU のみ使用環境（B）

：A + CPU 負荷

• 無線 LAN 電源のみ ON 環境（C）

：A + 無線 LAN 待機電力

• 無線 LAN 通信環境（D）

：A + 無線 LAN 待機電力 + 無線 LAN 通信電力

このことから，各デバイスの消費電力は以下の式で表すことができる．

• CPU：B - A

• 無線 LAN 待機電力：C - A

• 無線 LAN 通信電力：D - C

この式を元に，各デバイスの単位消費電力を計測した結果が下表である．

ここで，最低動作環境，及び無線LAN 待機電力は実際の計測時間とバッテリ消費量

から算出した値である．また，CPU 使用量はLinux の/proc/[Process ID]/stat から取

得できるプロセスのユーザーモードでの実行時間とカーネルモードでの実行時間の和

を用いた．そのため，データ取得時はjiffies と呼ばれる時間単位で取得でき，その粒度

は100 分の1 秒である．無線LAN 通信については，本実験においては送信のみを対象

とし，ifconfig コマンドから取得できる送信パケット数を参照した．通信における単位

使用量については，パケット数の他にデータ量によるものも考えられたため，255 バ

イトのパケットを用いた場合と511 バイトのパケットを用いた場合での電力使用量の

違いも測定したが，結果電力使用量の変化は送信パケット数について線形に変化して

いく傾向が見られたため，パケット数を単位として用いた．

アプリケーション別消費電力計測機構の評価

次に，計測した単位使用量を元にして，計算で求めた消費電力と実際の消費電力を

比較することで，消費電力計測の精度を求める．前節のネットワーク計測のプログラ

ムと円周率計算の両方の処理を行うプログラムを作成し，二つの処理を同時に行った

場合のCPU とネットワークの使用量を計測する．実験では10 分間の計測を行い，前

後1 分間を計測時におけるタイミングのずれを排除するために切り捨て，8 分間分の

データを有効データとして扱った．

実際に計測したデバイス使用量と前節で計測した単位消費電力から求められた合計

消費電力をまとめたものが下表である．

この表における値は理論値であり，ノード全体の予想電力使用量Eestimated は各デバ

イスの消費電力の和であるから，下式で表される．

Eestimated = 146.27 + 411.70 + 424.75 + 223.29

= 1206.01

一方，バッテリから取得できる消費電力量の実測値Ereal はバッテリから取得でき，

その値は1331 であった．ここで，実測値と理論値の間の誤差は式5.1 で表され，

結果，9.39%となる．この誤差が発生した原因としては，いくつかの原因が予想され

る．第一に既に触れたバッテリのセンシングにおける揺らぎによるもの，第二に

はデバイスの単位消費電力の測定誤差によるもの，第三は各デバイスを

区分けする際に無視してしまった要素によるものがあるだろう．無視してしまった要

素とは，無線LAN の受信電力であったり，OS オーバヘッドの揺らぎによるものなど

である．

このような誤差の取り扱いについては，動作保証機構において誤差分の余裕を持っ

てバッテリを確保することによって問題が解決できると考えられる．

消費電力量予測の評価

実際にデバイスを継続して動作させた際の消費電力量予測についての実験を行った．

実験環境は前節で用いたのと同じCPU と無線LAN に負荷をかけたものを1 時間動作

させ，N分後のバッテリ残量を予測した．予測アルゴリズムには移動平均アルゴリズム

を用いたが，本実験においてはデバイスの使用状態は実行中ほぼ一定であるため，予

測アルゴリズムの違いによる精度の違いは無視できる．実験結果におけるバッテリ残

量と予測値の誤差をプロットしたものが下図である．

図は1 分，5 分，10 分，20 分，30 分先の消費電力量を予測し，その予測値が実測値

とどれくらい離れているかを表している．結果から予測時間が長くなれば長くなるほ

ど誤差が大きくなる傾向があることが分かった．実際に消費電力予測を利用する際は，

こうした予測時間による誤差も考慮する必要があると考えられる．

まとめ

本研究では複数のアプリケーションが動作するバッテリ駆動のマイクロユビキタス

ノードにおいて，残バッテリ量からアプリケーション動作時間を予測したり，前もっ

て特定のアプリケーションが指定時間動作するためのバッテリ量を予約する機構が無

いことに着目した．このことは，これからもマイクロユビキタスノードの普及が進み，

社会の中でより重要度の高いサービスを提供していく上で大きな問題となる．

そのため，本論文では，特定のアプリケーションの動作時間保証を実現するpSurvive

を設計，実装し，評価を行った．pSurvive では，アプリケーションがマイクロユビキ

タスノード上の各資源を利用するのを監視し，どのアプリケーションがどれだけの電

力を消費しているのかを計測した上で，将来の消費電力を予測するアプリケーション

別消費電力計測・予測機構，及び，その予測結果を基に実際にアプリケーションの動

作保証を行うアプリケーション別動作保証機構の二つのモジュールから構成され，相

互に作用して動作時間保証を実現する．pSurvive はソフトウェアベースで実装されて

いるため，特殊なハードウェアを必要とせず，既に利用されている製品や，今後登場

するであろう製品に対しても低コストで導入することができる．

本研究の成果により，これまでバッテリ切れの問題によって信頼性や可用性が低かっ

たマイクロユビキタスノード上で動作時間保証を行うことで，アプリケーションの品

質保証を実現することができるようになる．このことにより，現在の利用者は意図し

ないバッテリ切れのリスクから解放され利便性が高まるとともに，サービスプロバイ

ダは新たに高信頼性を要求されるアプリケーションの開発が可能となる．これはマイ

クロユビキタスノードがさらに普及していくであろう今後の社会において，大きな利

益をもたらすものである．