新たなセンサをシステムへ導入するコスト

本節では新たにセンサをシステムへ導入する際に要するコストについて提案手 法を適応した場合と，従来とで比較する．従来は，新たな種類のセンサをシステ ムへ導入する度に各センサ専用にミドルウェアを開発する必要があった．一方開 発したミドルウェアを用いることにより，プラグインを記述するのみで新たな種 類のセンサを導入可能となる．図6.1に新たな種類のセンサをシステムに導入す るために，従来および提案手法を用いた場合で求められる作業をそれぞれ示す．

センサの仕様調査は従来であっても，提案手法用いる場合であっても必要な作業 である．仕様調査の次の段階で，従来ではセンサの仕様の調査結果を基にソース コードを記述しコンパイル後，実装する必要があった．一方で提案手法を用いる

! "#$ %&' () !"#$%&'

図 6.1 新たなセンサをシステムへ導入するのに要する作業工程

場合は，プラグインを記述するのみで良い．そのため，開発者にはプログラミン グ能力および入出力デバイス制御や組込機器，LinuxなどOSに関する知識は必 要とされない．このように提案手法を用いた場合，従来の作業工程を大幅に削減 することができる．また，開発者はセンサの仕様さえ知ってさえいれば，作業を 完了することが可能である．

6.2.1 時間およびデバッグ回数の計測

本研究で開発したミドルウェアの有効性を示すため，実際に，表6.2に示す技 能を持つ開発者A，B，Cが図6.1に示す工程を終えるのに要する時間およびデ バッグ回数をそれぞれ一度計測した．計測の条件としては，従来の手法について は表4.1に示すVantage Pro2について湿度を取得するミドルウェアをC言語を用 いて開発後，Armadillo-210に実装し，正常に動作するまでに要する時間および デバッグ回数を計測した．提案手法については，同じくVantage Pro2から湿度 を取得するプラグインを記述し，正常に値を取得できることを確認するまでに要 した時間およびデバッグ回数を計測した．なお，センサの仕様調査については両

タ取得手順などの仕様を知らせた．

表 6.2 開発者の技能

開発者A 開発者B 開発者C プログラミング経験（C言語） 最長300行 最長100行 最長3000行

組込機器を扱った経験 なし あり なし 入出力デバイス制御の経験 なし なし あり

Linuxを扱った経験 10ヶ月 12ヶ月 34ヶ月

計測の結果を表6.3に示す．開発者Aが従来手法を用いた場合，全ての作業を 終えるために790分間要したが，提案手法を用いた場合は25分で作業を完了す ることができ，従来手法に比べて作業時間を約97%減少させることができた．ま た，作業過程におけるデバッグ回数は従来手法を用いた場合は94回であったのに 対して，提案手法を用いた場合は1回であった．ここでのデバッグ回数とは単な る構文間違いなどのコンパイルエラーに伴うエラー処理の回数ではなく，ミドル ウェアを実行時にセンサと通信できない，目的のデータ項目を抽出できない，期 待する値を取得できない，といった問題に対して行った試行の回数である．従来 の手法を用いた場合，デバッグ回数が多くなる要因としては二点考えられる．一 点目は，センサとの通信制御に伴う問題である．ミドルウェアはセンサと接続し て動作を確認するまでは正常に動作しているかは判断できない．例えば，Vantage

pro2はRS232C通信を行うが，ボーレートやデータビットといった通信設定が間

違っていれば，メッセージは受信できない．またメッセージを受信できたとして も，データ要求コマンドを送信する前に未受信のメッセージを破棄していないこ とが原因で，受信したメッセージが期待するデータ項目を含んでいない場合があ る．二つ目は，組込機器特有の問題である．例えばArmadillo-210の場合，初期 状態ではシリアルデバイス経由でログインするためのプログラムであるgettyが 起動しており，シリアルラインを監視している．この状態のままでは，Vantage Pro2とシリアル通信し，メッセージを取得することはできない．このようなエ ラー要因はメッセージを受信できなかった，データを抽出できなかったといった 結果のみから推測せねばならず，専門知識を持たない者とって修正箇所の特定は

困難である．修正箇所が分からなければどのような文献，webページを調査すれ ば解決手法が得られるのかも判断できない．結果として，様々な手法を試すこと となり，デバッグ回数が多くなり時間がかかる結果となった．

一方提案手法を用いてプラグインを記述する場合，デバッグ回数は表6.3 に示 すように1回のみであった．デバッグ回数が少なく済んだ理由は，ミドルウェアが 正常に動作しない原因の特定が容易なためである．開発したミドルウェアを用い る場合，エラーの原因としてはプラグインの記述が間違っている以外になく，5.2 節で述べたデバッグ機能によりどの要素を修正すれば良いのかはエラーメッセー ジにより知ることができる．例えば，メッセージの受信ができない場合<Recver>

要素を改編する必要があるというメッセージが提示される．そのため，開発者は プラグインの該当する要素のみを改編するのみでデバッグが可能となる．さらに，

XML形式であるプラグインには各要素に<Command>や<Format>といった仕様 に応じたタグが付けられており，それぞれのタグに対応する仕様をセンサの仕様 書と照らし合わせて記述ができる．これらのことから提案手法を用いた場合は，

従来に比べてセンサをシステムへ導入するために要する時間を大幅に削減できた．

次に開発者Bが従来手法を用いた場合，作業を900分間行った段階では第一ス テップであるソースコードの記述さえ完了することができなかった．この理由と しては，開発者Bはミドルウェアを開発するのに十分なプログラミング能力を 持っていなかったことおよび既に述べたようにデバッグが困難であることが考え られる．一方提案手法を用いた場合，60分間でVantage Pro2からデータを取得 することに成功した．最後に開発者Cについては，提案手法を用いた場合のみ作 業時間を計測した．計測の結果，35分間で全ての作業を完了した．

このように提案手法を用いることで，従来手法に比べてセンサをシステムへ導 入するために要する時間を大幅に削減可能である．また，従来手法において作業 時間を増加させる要因となっていたデバッグ作業は，提案手法を用いた場合プラ グインを書き換えるのみで可能である．このことから，開発者Aに限らず開発者 B，Cにおいても1，2回でデバッグ作業を終えることができた結果となった．今 回ミドルウェアを開発した開発者らは皆，プログラミング経験とLinuxを扱った 経験を有していた．これらの経験が全くない者が同様の作業を行った場合，作業

表 6.3 時間およびデバッグ回数の計測結果

開発者A 開発者B 開発者C 既存手法 提案手法 既存手法 提案手法 提案手法 ソースコード／

プラグインの記述 410分 25分 900分 60分 35分

コンパイル 320分 - 未 -

-実装 60分 - 未 -

-合計 790分 25分 - 60分 35分 デバッグ回数 94回 1回 6回 2回 1回 を終えるのに要する時間およびデバッグ回数はさらに増すと推測できる．

6.2.2 プラグイン生成アプリケーションによるコストの軽減

開発したミドルウェアを用いることにより，XML形式のプラグインを記述する のみでセンサをシステムへ導入可能であることは既に述べた．プラグインはデー タ構造を明確に定義しているため，ソースコードとは異なりアプリケーションを 用いることで生成可能である．そのため，アプリケーションを用いることで，プ ラグインの記述はさらに容易になる．図6.2に開発したプラグインを生成するweb アプリケーションを示す．本アプリケーションはセンサのアクセス方式やメッセー ジ内からのデータ抽出手法といった項目をタブから選択したり，データ要求コマ ンドをテキストボックスに記述することによりXML形式のプラグインを生成す る機能を持つ．また，直接記述したプラグインをアップロードすることも可能で ある．アプリケーションにより生成した，またはアップロードしたプラグインは データベースに格納され，図6.3に示すように，以後ダウンロードして用いるこ とができる．同じセンサの仕様に対して記述されたプラグインを用いる場合は，

ダウンロードするだけで利用可能である．また，仕様が異なるセンサを扱う場合 にも，異なる要素のみを書き換えるだけで済む．このとき，各要素にはタグ付け がなされているので該当部分の改編は容易である．このように，開発したミドル