歴史的建造物監視アプリケーションの開発

まず，提案する開発プロセスの適用方法について，第2章で挙げた遺跡に対する 建築物監視アプリケーションを例に取りその詳細を述べる．当該アプリケーショ ンは，Torre Aquilaというイタリアにある歴史的建造物の，建築物としての状態 異常を監視することを目的としている．このアプリケーションで実現したいデー タフローは図2.1であり，加速度，歪み，温度，湿度の4種類のデータを計測し，

これらのデータに解析処理を加えることにより建築物の異常を検知する．この際，

歪みデータは計測値が変動しやすいものとし，計測値の誤差の影響を低減するた め，送信するデータは過去10回の計測値の平均値としている．監視対象となる建 築物の形状は地下1階を含む4階建ての塔となっており，うち地上3階の各フロ

アに計16個のノードと1個のベースステーションを配備している．このWSN及 びアプリケーションは，実際の建造物に対し配備され4ヶ月間運用された．アプリ ケーションの実装にはノードプログラミングを行うTeenyLIME[10]を用いている．

TeenyLIMEとは，個々のノードの動作を実装する言語であり，ノード間に共有タ

プルの概念を導入することでノード間通信に関する記述を簡潔に行えるよう設計 されている．各ノードは，主に建築のドメイン知識を基に，異常の兆候をより早 く検知できるデータの計測場所が選ばれ設置されている．これらのノードに対し，

各ノードに割り当てられるタスクは設置された場所に基づき決定される．例えば，

加速度データに関するタスクは，1階と3階の壁際に設置された特定のノードに対 して割り当てている．また，[7]では加速度のデータは重要であるとし，他のデー タよりも計測頻度を高めている．全ての加速度データを送信する場合，通信量，消 費電力量も増加してしまい，結果としてデータ計測期間が短くなってしまう．こ の問題に対し，Ceriottiらは，加速度データの通信時のみデータ圧縮を行うことで 通信量を減らし，データ計測期間を長くするよう品質調整を行なっている．圧縮 のアルゴリズムとしてはハフマン符号を用いた圧縮を採用している．

本開発プロセスを用いた場合，当該アプリケーションのアプリケーションロジッ クは，図4.1に示すDataflow-levelモデルとして表現可能である．このアプリケー ションロジックは，アプリケーションが必要とするセンサデータの計測，処理と 計測間隔に関する決定から作成可能である．また，このモデルからは自動変換に よりプロトタイプの実装が生成である．このように，開発者はデータフローに関 する記述のみでプロトタイプを得られるため，TinyDB等のマクロプログラミン グを用いた場合と同様，少ない工数でのプロトタイプ開発を実現しており，要件1 を満たしている．

図 4.1: 建築物監視アプリケーションのDataflow-levelモデル例

続いて，当該アプリケーションで実施されたタスク割当を本開発プロセスを用

いて実施した結果について記す．前述の通り，このアプリケーションでは建築物 の異常を早期に発見できるようノードの設置場所を決定し，設置場所に応じたタ スク割当を行なっている．このようなセンサノードの配置に合わせたタスク割り 当てを行うことで，異常検知の精度向上に努めている．本開発プロセスを用いた 場合，このタスク割当は，Node-levelモデルに対する変更として反映可能である．

ノードが担う役割，タスクの割り当ては，Node-levelモデルにおけるノードと役 割との関連で表現される．この関連の有無を変更することにより，ノードへの役 割，タスクの割り当てを設計できる．図4.2に，当該アプリケーションにおけるタ スク割り当ての様子を示す．ただし，簡単のため図中では3個のノードのみを取り 上げており，Beforeはプロトタイプ開発時に自動生成されたモデル，Afterはこの モデルに対し修正を加えたモデルである．修正前のモデルは自動生成されたモデ ルであり，各MemberRoleのもつdeploymentConditionの値と，ネットワークの 情報に基づき個々のノードに役割が割り当てられる．今回のモデルでは，自動変 換により，図中に存在する全てのノードに全ての役割が割り当てられている．こ れを，修正後のモデルのようにノードと役割との間の関連を変更することにより，

加速度の計測・送信を担うノード，歪みの計測・送信を担うノード，温度と湿度の 計測・送信を担うノードというように，ノードごとに異なる役割・タスク割り当 てを表現，設計可能である．このように，本研究のDSMLでは，NesCで品質調 整を行った場合と同様に個々のノードへのタスク割り当てに関する変更が可能で あった．また，この修正方法は，個々のノードの設置場所を鑑みて個々のノード に対し行うため，[7]でのタスク割当と同様の方法で同じ結果が得られたといえる．

また，データ計測期間をより長くするため，データ圧縮を行う通信方式の採用 を本開発プロセスで実施した結果について記す．これを本開発プロセスにて実現 する場合，Group-levelモデル上に設計を反映する方法とNode-levelモデル上に設 計を反映する方法の2通りが存在する．Group-levelモデルに設計を反映する場合 は，加速度データの計測を担うグループ内のリーダ・メンバ間の通信と，加速度 データの計測を担うグループとシンク間の通信にて，データの圧縮を行うことを 示すパラメタを設定すればよい．本開発プロセスでは，この設定はプロトタイプ 開発時に自動生成されたGroup-levelモデルに対するパラメタの変更として行う．

この変更の様子を図4.3に示す．Node-levelモデルに設計を反映する場合は，第2 章にて述べたNesCを用いた場合の品質調整と同様の考えに基づき，自動生成され たモデルで加速度データの送信・受信を担う各タスクの，データ圧縮に関するパ ラメタをすべて変更する．この変更の様子は図4.4に示す．また，図4.4の修正後 のモデルは，図4.3の修正後のモデルを自動変換した場合に得られるモデルに等し い．つまり，Group-level DSMLと変換規則により，Node-levelモデルを変更した 場合には複数のタスクに分散する修正箇所を，グループ内通信として1箇所にま とめて記述することが可能である，という結果が得られた．

このように，本研究のDSMLでは，TinyDBの様なマクロプログラミングでは実 現出来なかった個々のノードへのタスク割当，通信方式の変更が可能であり，NesC

図 4.2: 建築物監視アプリケーションのNode-levelモデルに対する再設計

locationCondition = WHOLE topology = TREE

: Group

: Sink

locationCondition = WHOLE topology = TREE

: Group

locationCondition = WHOLE topology = TREE

: Group

selectionPattern = ANY : LeaderNode

transmissionCondition = 30 sec samplingCondition = 0.2 sec dataType = ACCELERATION selectionPattern = ALL

: MemberNodes selectionPattern = ANY

: LeaderNode

transmissionCondition = 10 min samplingCondition = 10 min dataType = DEFORMATION selectionPattern = ALL

: MemberNodes

outputDataType = StracturalCondition

inputDataTypes = {ACCELERATION, DEFORMATION, TEMPERATURE, HUMIDITY}

function = DeseaseDetection

: FusionOperator

duration = 10 min timeWindow = 100 min function = AVERAGE inputDataType = DEFORMATION : TemporalAggregationOperator encryption = NONE

compress = NONE : Communication

encryption = NONE compress = NONE : Communication

transmissionCondition = 10 min samplingCondition = 10 min dataType = TEMPERATURE selectionPattern = ALL

: MemberNodes

transmissionCondition = 10 min samplingCondition = 10 min dataType = HUMIDITY selectionPattern = ALL : MemberNodes encryption = NONE

compress = NONE : Communication encryption = NONE

compress = NONE : Communication

HUFFMAN HUFFMAN

図 4.3: 建築物監視アプリケーションのGroup-levelモデルに対する再設計

図 4.4: 建築物監視アプリケーションのNode-levelモデルの一部とモデルに対する 再設計

では変更箇所が各タスクに分散してしまう問題を，グールプ内のリーダ，メンバと いう集合に対して集約して記述することで解決可能である．すなわち，本開発プロ セスではノードへのタスク割り当てと通信方式に関する設計が可能であり，要件2 を満たしているといえる．また，前述のように，これらのGroup-level，Node-level のモデルの修正は，プロトタイピングフェイズにて作成したDataflow-levelのモデ ルから自動生成されたモデルに対し行う．すなわち，開発者はこれらのモデルを，

Dataflow-levelのモデルに基づき手動で変換して作成する必要や，スクラッチから

記述する必要はない．結果として，提案する開発プロセスは手動変換により起こ りうる誤りを排除し，成果物の再利用が可能であるといえる．このように，本開 発プロセスは要件3を満たしいているといえる．