早稲田大学大学院基幹理工学研究科情報理工学専攻深澤研究室

(1)

無線センサネットワークアプリケーション開発におけるデータ品質最適化に関する研究

2012 年 1 月 31 日 ( 火 ) 提出

指導 : _{深澤良彰教授}

早稲田大学大学院基幹理工学研究科情報理工学専攻深澤研究室

学籍番号 : 5110B061-1

清水遼

(2)

第1章はじめに 1

1.1 無線センサネットワークアプリケーションとは. . . . 1

1.2 無線センサネットワークアプリケーション開発の現状と提案する開発プロセス . . . . 2

1.3 本論文の構成 . . . . 4

第2章 WSNアプリケーション開発における問題 6 2.1 WSNアプリケーション開発例: Heritage building monitoring . . . . 6

2.2 ノードプログラミングによる開発 . . . . 7

2.3 マクロプログラミングによる開発 . . . . 9

2.4 ハイブリッド方式による開発 . . . . 9

2.5 各開発方式における問題点のまとめ . . . . 10

第3章提案する開発プロセス 12 3.1 開発プロセスの構成 . . . . 12

3.2 DSMLの設計 . . . . 13

3.2.1 Dataﬂow-level DSML . . . . 13

3.2.2 Group-level DSML . . . . 16

3.2.3 Node-level DSML . . . . 18

3.3 変換規則の設計 . . . . 20

3.3.1 Dataﬂow-levelモデルからGroup-levelモデルへの変換規則 . 21 3.3.2 Group-levelモデルからNode-levelモデルへの変換規則 . . . 22

3.4 開発プロセス中の各フェイズの詳細 . . . . 26

3.4.1 プロトタイピングフェイズ . . . . 26

3.4.2 チューニングフェイズ . . . . 27

3.5 実装 . . . . 30

第4章ケーススタディ 32 4.1 提案開発プロセスの適用による開発例 . . . . 33

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

4.1.2 患者状態監視アプリケーションの開発 . . . . 37

4.2 提案DSMLの記述能力検証 . . . . 41

(3)

5.2 自動変換の有用性 . . . . 44 5.3 本開発プロセスの限界 . . . . 45 5.4 本開発プロセスと要件との対応 . . . . 46

第6章関連研究 47

6.1 WSNアプリケーション開発に関する研究. . . . 47 6.1.1 WSN向けDSL . . . . 47 6.1.2 WSNアプリケーション開発支援ツール . . . . 48

6.1.3 WSNアプリケーション開発のためのモデル駆動開発 . . . . 49

6.2 WSN管理の支援に関する研究 . . . . 50

第7章おわりに 53

7.1 まとめ . . . . 53 7.2 今後の課題 . . . . 53

(4)

1.1 無線センサネットワークアプリケーションとは

無線センサネットワーク(WSN: Wireless Sensor Network)とは，無線通信により実世界の計測データを伝搬するセンサネットワークである．WSNを構成するデ

バイス(センサノード)は様々な種類のものが開発・販売されているが，主な特徴

としては小型であること, 1つないしは複数のセンサを搭載していること，無線通信機能を持つこと，バッテリ駆動であること，小型ゆえに限られた計算資源しか持たないこと等が挙げられる[46]．また，無線通信技術や電子機器の製造技術の進歩により従来のセンサ機器よりも低価格である，通信や電源供給に有線を用いないため敷設時の制限が少ないといった特徴も有する[2]．更に，センサノードはOS を搭載しており，用途に応じてソフトウェアを開発し，実行するアプリケーションを変更可能である．

このWSN上で動作するアプリケーションに対する需要は増加している．現在，

センサデータを用いたアプリケーションが様々な分野に適用されており注目を集めいている．WSNの適用により，より多様な場所のセンサデータを，より低いコストで取得することが可能となる．例えば，広域で人手が届きにくく，デバイスやケーブルの敷設，電源の確保が困難な場所や，美観の問題でケーブル等の設置に制限のある場所への適用が考えられる．前者に対しては森林[22]や火山[43]への敷設，後者に対しては歴史的価値のある建造物[7]や美術館への敷設の例が挙げられる．このような広範への適用可能性のため，WSNとその上で動作するアプリケーションに対する需要は高まっているといえる．

最も一般的なWSNアプリケーションは，データの計測と，計測したデータの送信を定期的に行うものである．WSNアプリケーションは，どの様なタイミングでデータの計測や送信が実行されるかという観点から2種類に分類可能である[3]．1 つは決められた時間間隔に基づき定期的なデータ計測，送信を行うアプリケーションである．もう1つは，事前に定義した特定のイベントを検知した場合にデータ計測，送信を行うアプリケーションである．[3]では，この計測・送信の実行タイミングを含む8つの視点から23のアプリケーションに対し分類を試みており，うちデータの計測・送信ともに定期的に実行するアプリケーションが10個と最も多いという結果を示している．また，[25]でも同様の観点を含む5つの観点から28のアプリケーションを分類し，うち21のアプリケーションが定期的なデータ計測・送信を行うアプリケーションであるとしている．このように，現存する多くのWSN

(5)

アプリケーションが，定期的な計測，通信を行うものであることが言える．

1.2 無線センサネットワークアプリケーション開発の現状と提案する開発プロセス

WSNアプリケーション開発では，環境に依存する品質を最適化することが課題となる．センサを用いたアプリケーションでは，物理世界の状況を正確に取得するために，特に取得するデータに関する品質が重要となる．データ品質とは，ここではデータの欠損率，データの計測期間，データの新鮮さを指す．これらのデータ品質は実行環境に依存することが知られている[38][47]．実行環境とは，建造物や人を含む物理世界，配備されたセンサノードの仕様や数，密度を指す．故に，WSN アプリケーションの開発者は，データ品質への要求を満たすために，対象となる実行環境ごとにデータ品質を調整しなければならない．データ品質の調整の為に，

開発者はプロトコル，データ圧縮や暗号化の有無といった通信方式や，ノードが担うタスクや役割に関わる個々のノードの動作を実行環境にあわせて決定する．例えば，障害物が多い屋内は，電波が減衰しやすくデータの欠損率が高くなりがちである．このような環境で動作するアプリケーションを開発する場合，開発者は利用可能な通信経路をすべて用いるルーティングプロトコルを用いる，等といった決定をする．これにより，通信の信頼性を高めることでデータの欠損率を低減する．

実行環境ごとにデータ品質を最適化するようアプリケーションの設計をするためには，開発の早期段階でプロトタイプを開発する開発手法が有効である．この開発手法では，まず実行環境におけるデータ品質を測定するための実行可能なコー

ド(＝プロトタイプ)を開発する．その後，プロトタイプを実行し，その測定結果

に基づきアプリケーションの再設計を行う．本論文ではこの再設計を品質調整と呼ぶ．プロトタイプを実行環境上で実行することにより，シミュレーションではモデル化に手間がかかる物理環境の影響を受けるデータ品質を比較的容易に計測できる．図1.1に，前述の開発プロセスを示す．

このような開発プロセスにおいて，現状ではアプリケーションの設計・実装に関する支援が十分でない．この開発プロセスでは，実装したアプリケーションを実行，データ品質を測定し，データ品質に対する要求を満たすためにどの様な変更を加えるかを決定する分析に関わる工程と，アプリケーションの設計・実装を行う開発に関わる工程が存在する．分析に関わる工程においては，繰り返し行うアプリケーションの配置がスムーズに行えること，データ品質の測定が容易に行えることなどが求められる．また，開発に関わる工程では，プロトタイプが少ない工数で開発できること，細やかな品質調整が行えること，成果物がシームレスに再利用できることが求められる．前者については，プログラムの再配備，WSNのモニタリングに関する研究やツールによる支援がなされている．しかし，後者につ

(6)

図 1.1: 従来のWSNアプリケーション開発プロセス

いては，3つの要件を満たしつつ開発を行うための十分な支援がなされていない．

プロトタイプを用いた開発プロセスにおいて，開発に関わる工程に求められる 3つの要件を以下に記す．

要件1. 品質調整により多くの工数を割くために，プロトタイプをなるべく少ない工数で開発可能であること

要件2. データ品質への要求を満たすため，細かな粒度での品質調整が可能であること

要件3. 開発の生産性を高めるため，成果物のシームレスな再利用が可能であること

前述のように開発に関する支援が不十分であるため，これらの要件を満たしつつWSNアプリケーションを開発することは難しい．現在の一般的なWSNアプリケーション開発では，WSNの専門家が個々のノードの振舞を実装するノードプログラミングが用いられている．この方法では，アプリケーションをWSNを構成するセンサノードの分散・協調動作として実現する．そのため，開発者は分散するノード同士が連携するための通信方式と，個別ノードの動作を設計・実装する必要がある．これらの設計・実装には多くの工数が必要となる．これは，WSNの専門的な知識を要すること，アプリケーションの機能要求を分散・協調動作に落としこむ方法論が確立されていないことなどのためである．この負担を低減するため，

アプリケーションを分散・協調動作としてではなく，ノード集合或いはWSN全体の動作として記述するマクロプログラミング言語が数多く提案されている．しかし，これらの言語では，開発者が記述できる内容を減らしているため，通信方式や個別ノードの動作に関わる記述が制限されてしまい，詳細な品質調整が難しくなっている．例えば，通信方式に関してはミドルウェアで固定されており，言語上では変更が出来ず，通信方式に関わる品質調整が出来ないことが起こりうる．し

(7)

たがって，単一の言語を用いた開発では，前述のプロトタイプを用いた開発への要件1，2のいずれかを満たすことができない．また，複数の言語を組み合わせて用いた開発では，異なる言語で記述された成果物の変換を手動で行う必要があり，

成果物の再利用がしにくく，また変換時に誤りが混入する恐れがある．よって，要件3を満たすことができない．マクロプログラミングを用いる開発や複数の言語を組み合わせる開発によって，実世界に配備するアプリケーションを開発した報告はほとんどなく[25]，実際に運用されているアプリケーションの多くはノードプログラミングを用いたものである．

本研究では，異なる抽象度を持つ複数のモデリング言語と，それらによって記述されたモデル間の変換規則を定義し，これらを用いるモデル駆動開発プロセスを提案する．本研究にて提案する開発プロセスでは，アプリケーション開発をデータフロー設計，ネットワーク上でのマクロな動作の設計，個々のノードの動作の設計に分割し，設計対象に合わせたドメイン特化モデリング言語(DSML: Domain Speciﬁc Modeling Language)を利用可能とすることで，プロトタイプを用いた開発時の要件1と2を実現する．これらのDSMLは，前節で述べたWSNアプリケーションとして最も典型的な，定期的なデータ計測・送信を行うアプリケーションを開発可能なよう設計した．プロトタイプを開発する場合には，データフローのみを記述するDSMLを用いることで，個々のノードの振舞を実装する場合よりも少ない工数でのプロトタイプ開発(要件1)を実現する．品質を調整する場合には，

ノードの集合或いはノード毎の処理を記述するDSMLを用いることで，データフローのみを記述する場合よりも詳細な品質の調整(要件2)が実現できる．また，本開発プロセスでは，DSMLで記述されたモデル間の変換規則を定義し自動化することで，成果物の再利用(要件3)を実現すると共に手動変換による誤りの排除を実現した．

本開発プロセスの妥当性を確認するため，実際の環境に配備され，センサネットワーク分野の著名な学会にて成果が報告されている，7種類のWSNアプリケーションを用いたケーススタディを実施した．対象としたアプリケーションに対し，

実際に本開発プロセスを適用し，前述の要件1〜3が満たされることをケーススタディを通して示した．また，本研究で定義したDSMLを用いて記述し，その記述能力についての検証を行った．その結果，5種の定常的な計測を行うWSNアプリケーションを記述可能で有ることを確認した．

1.3 本論文の構成

本論文の構成は以下の通りである．まず，第2章では現状のWSNアプリケーション開発と，開発時に起こりうる問題について，具体例を用いて述べる．続く第3章では，2章で述べた問題を解決するための，提案する開発プロセスについて詳述する．第4章では提案する開発プロセスの適用を検証するためのケーススタディについて述べ，第5章ではDSMLの記述能力や変換規則の有用性，本開発プ

(8)

ロセスの制限について述べることで開発プロセスの有用性について議論する．更に，第6章で関連研究について詳述し，最後に第7章ではまとめと今後の課題について述べる．

(9)

における問題

2.1 WSN アプリケーション開発例 : Heritage build- ing monitoring

WSNアプリケーションの開発事例として，歴史的建造物の健康状態を監視するアプリケーション[7]を開発する場合を考える．これは，各センサノードが加速度，

歪み，温度，湿度の4種類のデータを定期的に計測・送信し，集められたデータをもとに建築物に異常がないかを調べるアプリケーションである．ただし，歪みのデータについては，計測値が変動しやすいため，過去10回の計測値の平均値を異常検知に用いている．本アプリケーションに求められるデータフローは図2.1のように表現できる．WSNではデータに対する集約・融合処理をネットワーク内で実行することも可能であるが，今回対象とするアプリケーションでは建築物の異常検知処理はネットワークの外で実行している．

図 2.1: 建築物監視アプリケーション[7]のデータフロー例

このアプリケーションの開発にあたり開発者らは，前述の4種類のデータのうち加速度のデータを重要なデータとして位置づけており，加速度のデータは高頻度で計測することとしている．この結果，加速度データの計測を担うセンサノードは電力消費量が多くなると考えられる．消費電力量が多くなることはデータ計測期間が短くなるという悪影響を及ぼす．また，センサノードの配置場所，特に加速度や歪みのデータを計測する場所は，建築に関する知識に基づき，異常の兆候を早期に検知できるよう選択している．つまり，各センサノードに割り当てられるタスクは，ノードの物理的な配置場所によって決定している．したがって，対

(10)

象アプリケーションでは，配備されたすべてのセンサノードに対して同じタスクを割り当てず，センサノードの配置場所に基づき，ノードごとに計測・送信するデータの種類が異なるようタスクの割り当てが行われている．

更に，加速度データは計測頻度が高いため，これに比例し通信量も多くなってしまう．通信量が多くなった結果として消費電力量も大きくなり，データ計測期間が短くなってしまう．この問題に対応するため，対象アプリケーションでは，加速度データのみデータを圧縮して送受信を行うプロトコルを採用している．このように対象アプリケーションではノードごとに異なる役割の割当やデータタイプごとに異なる通信方式の採用をしている．

2.2 ノードプログラミングによる開発

前節で述べたようなWSNアプリケーションを開発する上で，現在最も一般的な方法は，個々のノードの動作をプログラミング言語を用いて記述するもの(ノードプログラミング)である．ノードプログラミングを実現する言語の代表としては NesC[13]が挙げられる．NesCは，WSN用OSであるTinyOS[17]上で動作するプログラムを記述する言語であり，OSが提供するAPIを用いることでハードウェアに非依存なプログラムを記述できる．このNesCを用いて，対象アプリケーションを実装する場合を考える．

図2.1に示すデータフローをNesCを用いて実装したプログラムの記述例の一部

を図2.2，2.3に記載する．ただし，建築物の異常検知処理はデータ受信後に別の

コンピュータ上で行われているため省略している．

図2.2は，データの計測を担うノードのプログラムである．このプログラムにはタイマーを用いた時間の管理，計測処理の呼び出し，パケットの作成やデータ送信に関する記述が含まれている．

図2.3は，データの中継を担うノードのプログラムである．このプログラムでは，目的のデータを受信後そのまま送信を行なっているが，データの集約や融合を行う場合には計測データを送信してくるノードを把握し，計測ノードと集約／

融合処理ノードとの協調動作としてプログラムを記述する必要がある．

また，これらのプログラムを記述する際には，開発者はどのセンサノード間で通信を行うか，用いるルーティングプロトコルをどうするか，通信時にデータの圧縮や暗号化は必要か，といった，通信時の設定も細かに記述する必要がある．このようなノード毎の動作や通信の設定に関する記述により，開発者はデータ品質に対する要求を満たす為の詳細な調整が可能となる．

対象アプリケーションでは，ノードごとに異なる役割を割り当てることや特定の計測データに対してのみデータ圧縮を実行する，といった品質調整を実施していた．NesCであれば，前者は各ノードに割り当てる役割に応じて，ノードごとにプログラムを開発することで実現可能である．後者については，データの送信側にパケット作成時に圧縮処理を追加し，データの受信側にはパケット受信時に圧縮

(11)

...

// Time management

event void Timer.fired(){ // Data sensing

call Temperature.read();

} ...

event void Temperture.readDone(error t result, uint16 t data){ msg->temperature = data;

// Data transmission

call Collection.send(AM BROADCAST ADDR,

&msg, sizeof(temperature msg t));

} ...

図 2.2: NesCでの建築物監視アプリケーション実装例(計測・送信タスク)

...

// Data receive

event message t *Receive.receive(message t *msg, void *payload, uint8 t len){

if(len == sizeof(temperature msg t)){ // Data transmission

call Collection.send(...);

} } ...

図 2.3: NesCでの建築物監視アプリケーション実装例(送受信タスク)

(12)

処理に対応する解凍処理を追加することによって実現可能である．しかし，ノードプログラミングを用いた場合には，実現したいデータフローと実装との間の乖離が大きく，またデータフローを実装に落としこむ手法が確立していないため，図 2.1に示すような単純なデータフローを実現する場合でもプロトタイプの開発には多くの工数がかかってしまう．

2.3 マクロプログラミングによる開発

2.2節で述べた実装における工数を低減するため，ノードの集合に対する動作や，WSN全体への命令を記述するプログラミング言語(マクロプログラミング) が，6.1.1節でも詳述するように数多く提案されており，これらを用いて開発する方法も考えられる．マクロプログラミングの例としてはTinyDB[24]が挙げられる．

TinyDBではWSNをデータベースとみなし，図2.4に示すようにSQLライクな

文法でWSNから計測データを取得可能である．対象アプリケーションをTinyDB を用いて実装した例の一部を記載する．TinyDBでは，主にSELECT節にて要求するデータの種類を，SAMPLING PERIOD節にて計測(と送信)間隔を記述する．

また，各データへの集約処理がある場合にはSELECT節にてその処理を記述する．

(例：温度の平均＝ AVG(temp))

SELECT accel x, accl y, temp, humidity FROM sensors

SAMPLING PERIOD 5000

図 2.4: TinyDBでの建築物監視アプリケーション実装例

このように，マクロプログラミングではノードプログラミングに比べ非常に簡潔な記述でWSNからセンサデータを取得することが可能であり，プロトタイプを得ることも容易となる．一方，品質を調整すること，今回のアプリケーションではノードごとに異なる役割の割当や計測データによって圧縮を実行することは困難である．ノードごとの異なる役割の割当については，TinyDBではすべてのノードに対し同じタスクを課すことでプログラムの記述を簡潔にしているため不可能である．また，データ圧縮の実行については，TinyDBにおける通信方式はミドルウェアによって固定されているため，基本的にはアプリケーション開発者には変更できない．

2.4 ハイブリッド方式による開発

2.2，2.3節で述べたように，WSN向けのプログラミング言語には，開発者が記

述した命令の影響範囲が，WSN全体や単一ノードのみといったように異なる言語

(13)

が存在する．このような命令の影響範囲の異なる言語を，本論文では抽象度の異なる言語と呼ぶ．言語による抽象度の違いを利用し，抽象度の異なる複数の言語を用いて開発するハイブリッドな手法も考えられる．

具体的な開発方式としては，プロトタイプ開発時にはマクロプログラミングを用いて早期開発を実現し，その後の品質調整時には詳細な記述が可能なノードプログラミングを用いるというような開発である．このハイブリッドな開発方法の全体像を図2.5に示す．このような開発プロセスを用いれば，要件1，2の双方を同時に満たすことが可能となる．

図 2.5: マクロプログラミング，ノードプログラミングの双方を用いたハイブリッドな開発プロセス

しかし，開発されたプロトタイプは，品質調整時に用いられる言語とは異なる言語で記述されているため直接再利用することができない．プロトタイプを再利用するためには，マクロプログラミング言語からノードプログラミング言語への変換が必要となる．変換方法は手動変換と自動変換の2つが考えられるが，手動での変換では誤りが混入する恐れがあり，自動での変換のためには各言語間に対し変換規則を用意する必要があるため，いずれにせよプロトタイプの再利用のために工数を割く必要が生じる．

2.5 各開発方式における問題点のまとめ

以上の3つの方法が，プロトタイプを用いた開発への要件のうち，どの要件を満足するかについてのまとめたものが表2.1である．ノードプログラミングでは，

個々のノードの動作やノード間通信に関する記述が可能なため要件2を満たす．しかし，実現したいデータフローと実装との間の乖離が大きく要件1を満たすことが難しい．マクロプログラミングでは，実現したいデータフローをWSN全体或いはノード集合の動作をして簡潔に記述可能なため要件1を満たすが，ノード間の通信方式等は変更不可であるため要件2を満たすことは難しい．異なる抽象度

(14)

表 2.1: プロトタイプを用いた開発への要件と既存の開発方法要件1 要件2 要件3 ノードプログラミング満たさない満たす満たすマクロプログラミング満たす満たさない満たすハイブリッド方式満たす満たす満たさない

の言語を複数用いるハイブリッドな開発方式では，プロトタイプ開発時にマクロプログラミングを，品質調整時にノードプログラミングを用いることで要件1と2 を同時に満たす．しかし，複数の言語を用いるため，プロトタイプ開発時の成果物をそのまま品質調整時に利用することができず，要件3を満たせない．

以上のように，既存の開発方法ではすべての要件を同時に満たすことはできない．そこで，本論文ではこの問題を解決する開発プロセスを提案する．

(15)

3.1 _{開発プロセスの構成}

本節では，第2章で述べた問題を解決するために提案する開発プロセスについて述べる．第2章にてハイブリッドな開発手法に関連して述べた通り，要件1，2 を同時に満たすために抽象度の異なる複数の言語を用いることは有効である．複数の言語を用いた際の問題点は成果物の再利用であった．そこで，本研究では抽象度の異なる複数の言語を定義し，更にそれらの言語で開発された成果物を再利用するための自動変換を実現する変換規則も定義する．また，この方策を実現するため，モデル駆動開発(MDD: Model Driven Development)の概念を採用した開発プロセスを作成した．モデル駆動開発では，開発者は対象とするアプリケーションを，DSMLを用いてモデルとして記述し，記述されたモデルは変換規則に基づく自動変換によってより詳細なモデルへと変換され，最終的に実装が出力される [34]．

本開発プロセスは，抽象度の異なる3つのDSMLと，DSMLで記述されたモデル間の自動変換のための変換規則からなるMDDプロセスである．DSMLは，アプリケーションのデータフローを表現するDataﬂow-level，ノードグループの構成と処理を表現するGroup-level，個々のノードの役割とタスクを表現するNode-levelの3 つを定義した．変換規則はDataﬂow-levelからGroup-levelへの変換，Group-level

からNode-levelへの変換に対して定義しており，モデル間の情報の対応関係と，変

換後のモデルに新たに追加する情報を含む．DSML及び変換規則の設計に関する詳細は3.2，3.3節に記す．

また，本開発プロセスは，従来のプロトタイプを用いた開発と同様，プロトタイプ開発を行った後，品質の調整を行う．本開発プロセスではプロトタイプ開発を行うフェイズをプロトタイピングフェイズ，品質調整を行うフェイズをチューニングフェイズと呼ぶこととする．図3.1に，提案する開発プロセスの全体像を示す．プロトタイピングフェイズとは，機能要求を満たすためのデータフローを決定し，プロトタイプの開発を行うフェイズである．開発者はDataﬂow-levelのモデルのみを記述することで，自動変換によりプロトタイプの実装を得ることができる．このように，ネットワークに非依存なデータフローのみを決定からプロトタイプを生成することにより要件1を満たす．この際，Dataﬂow-levelのモデルから Group-level，Node-levelのモデルも自動生成することで，後の品質調整時に再利用が可能となる．これにより，要件3を満たす．チューニングフェイズとは，プ

(16)

ロトタイピングフェイズで得られたプロトタイプを，データ品質への要求を満たすように修正するフェイズである．開発者は3つのDSMLのうち任意の抽象度の DSMLを用いてプロトタイプを修正することが可能であり，細やかな品質調整が可能となり，要件2を満たす．これら2つのフェイズの詳細については3.4節に示す．また，上述のアプリケーション設計に関わるフェイズの他に，品質調整を行うために，自動変換で得られたプロトタイプを対象となる実行環境で実行し，その品質を測定，分析した後，現状のモデルに対しどのような調整を施すかを決定するフェイズが存在する．本研究では，この分析フェイズは対象外とするが，分析に関わるサポートについては第5章にて議論する．

3.2 DSML の設計

本開発プロセスでは3つのDSMLを定義している．Dataﬂow-level DSMLは，アプリケーションの機能要求を実現するために必要なデータフローを表現するために定義した．また，WSNアプリケーションは，最終的には個々のセンサノードの動作として実現されるため，このノード毎の動作を表現するためにNode-level DSML を定義した．このデータフローとノード毎の動作との間にはネットワーク管理，タスク割り当てといった乖離が存在する．そこで，この乖離を埋めるため，データフローを実現するための処理を，個々のノードの動作としてではなく，ネットワーク依存なノード集合の動作として簡潔に表現するためにGroup-level DSMLを定義した．

このように抽象度の異なるDSMLを用いることにより要件1，2を満たす．プロトタイプ開発時にはネットワークに非依存なデータフローを記述することにより，簡潔な記述でプロトタイプが得られるため要件1が達成される．また，品質調整時にはプロトタイプ開発時に用いたデータフローを記述するDSMLだけでなく，ネットワーク内のノードグループや個々のノードの動作を記述するDSMLも用いることで細やかな品質調整が実現できるため要件2を満たす．

本節では個々のDSMLについて詳述するが，ここで各DSMLの記述例の対象として用いるアプリケーションについて述べる．DSMLの記述例として，室内温度を取得するWSNアプリケーションを開発する場合を考える．対象アプリケーションは，特定の部屋に配備されたセンサノードから温度データを取得し，それらの平均値を定期的に取得するアプリケーションとする．このアプリケーションを実現するために必要なデータフローは図3.3のように表現できる．以下の各節では，

このデータフローを実現するモデルを記述例にとる．

3.2.1 Dataflow-level DSML

本研究ではネットワークに非依存なデータフローを表現するためのDSML，Dataﬂow-

level DSMLを定義した．これは，データフローが，WSNアプリケーションが達

(17)

Developer's View

Tuning PhaseAnalyzing PhasePrototyping Phase

System's view

: Functional Requirement

<<manual>>

<<process>>

Dataflow-level Modeling

<<physical>>

: Dataflow-levelModel

<<automatic>>

<<process>>

Dataflow2Group Transformation : Dataflow2Group

TransformationRule

<<physical>>

: Group-levelModel

<<automatic>>

<<process>>

Group2Node Transformation : Group2Node

TransformationRule

<<physical>>

: Node-levelModel

<<automatic>>

<<process>>

Code Generation : CodeGeneration

<<physical>> Rule : ApplicationCode

<<manual>>

<<process>>

Performance Analysis

<<manual>>

<<process>>

Performance Monitoring

: Requirement forDataQuality

: TuningFactor

: QualityDatum

<<manual>>

<<process>>

Dataflow-level Tuning

<<manual>>

<<process>>

Group-level Tuning

<<manual>>

<<process>>

Node-level Tuning

<<physical>>

: Group-levelModel

<<physical>>

: Node-levelModel

<<automatic>>

<<process>>

TransformationRule

<<automatic>>

<<process>>

TransformationRule

<<automatic>>

<<process>>

Rule

<<physical>>

: ApplicationCode

図 3.1: 提案する開発プロセスの全体像

(18)

成すべき機能を表現するものだからである．

データフローを表現するためには，データの出力を行うデータソース，得られたデータに対して集約または融合処理を行う中間処理地点，最終的にデータを集めるデータシンクの3つと，これらの要素を接続し，データの移動経路を表すリンクが必要となる．本研究では，集約処理とは複数の同種のデータを入力とし，入力から一つの代表値を出力する処理を，融合処理とは複数の異種のデータを入力とし，一つの代表値を出力する処理をそれぞれ指す．

これらの構成要素からなるデータフローを記述可能なように設計したDataﬂow-

level DSMLの定義にあたるメタモデルを図3.2に示す．データフローを表現する

為に必要なデータソースはDataSourceに，中間処理地点はAggregationPointと FusionPointに，データシンクはDataSinkに，リンクはクラス／オブジェクト図中の関連に対応している．また，メタモデルには各要素に必要なパラメタも定義されている．例えば，データソースにおいて計測に必要な各種情報（計測間隔，送信間隔など）がDataSourceの属性に対応している．集約処理については，WSNが時空間的に分散するデータを扱うことから，時系列の計測値から代表値を得る処理と，空間的に分散する計測値から代表値を得る処理の二種類が必要と考え，各々に対応する要素を用意した．

図 3.2: Dataﬂow-level DSMLのメタモデル

Dataﬂow-level DSMLでの記述例として，図3.3に示すデータフローを記述したモデルが図3.4である．モデルに必要な情報はデータソースにて取得したいデータの種類，中間処理地点にて実行した集約・融合処理の種類と，計測時に必要な各種

(19)

情報のみである．このモデルから，アプリケーションではデータソースが30秒間隔で温度データを出力し，集約処理地点がこのデータの平均値を計算しデータシンクへと送られることがわかる．このように，Dataﬂow-level DSMLでは，WSN アプリケーションで実現したいデータフローを非常に簡潔にモデルとして表現可能である．

図 3.3: 室内温度を計測するWSNアプリケーションに必要なデータフロー例

図 3.4: Dataﬂow-levelモデルの記述例

3.2.2 Group-level DSML

続いて，WSN全体をノードグループとして抽象化して表現する Group-level DSMLを定義した．WSNアプリケーションは，実行時には複数のセンサノードで構成される無線ネットワーク上に割り当てられるが，第2章でも述べたとおり個々のノードの動作を設計することは難しい．これに対し，WSNをノードグループとして抽象化することは，ネットワーク上でのアプリケーションの動作を，ノードグループのマクロな動作として簡潔に表現可能である．よって，本研究ではGroup-level DSMLを定義した．

本DSMLでは，WSNは階層的なノードグループとしてモデル化し，各グループはリーダとメンバから構成されるものとした．本研究が対象とするアプリケーションにおける，ネットワーク上でのデータの流れは，計測ノードからマルチホップ通信を通し，必要に応じて集約・融合処理を経て段階的に収集地点となるノードに届けられる，というものである．リーダ・メンバ型のグループでは，データの流れがメンバからリーダとなることが主であり，リーダはメンバから受け取ったデータをより上位のグループのリーダへと流すため，対象とするアプリケーションのデータの流れと親和性が高いと考えられる．よって，本研究ではリーダ・メンバ型のグループを採用した．

(20)

このようにWSNをリーダ・メンバ型の階層的なノードグループとして表現するためのGroup-level DSMLの定義が図3.5に示すメタモデルである．1つのノードグループは，1つのリーダと1つないしは複数のメンバからなる．これは，メタモデル中のGroupがLeaderとMemberと関連を持つことと対応する．ネットワーク内でデータを収集地点として必要となるシンクノードは，リーダの特殊なケース Sinkとして定義している．Memberの特化としてGroupを定義することにより階層的なグループを表現している．リーダは集約・融合処理を，メンバは計測処理を担い，これらの処理はLeaderに関連を持つOperatorとMemberNodesのもつ属性に対応する．また，データ品質を調整する為には，グループ内ネットワークトポロジやリーダ・メンバ間での通信方式，リーダ・メンバの選択条件を調整可能である必要がある．よって，これらの情報については対応するパラメタを定義し表現可能としている．

図 3.5: Group-level DSMLのメタモデル

Group-level DSMLを用いて，図3.3に示す室内温度計測アプリケーションのモデルを記述した例が図3.6である．この図から，当該アプリケーションでは，1つのグループとして捉えたWSN全体にはシンクとメンバとしてのグループが1つずつ存在し，更にこのグループ内には，温度データを30秒毎に計測・送信するメンバと，メンバから受信したデータに対して平均を取るリーダが存在することがわかる．また，いずれのグループにおいても，ネットワークトポロジはツリー型であり，リーダとメンバとの間の通信では圧縮・暗号化を行わないこと，リーダの選択条件は特に指定されておらず，メンバとしての処理は全てのノードに割り当

(21)

てられることが表現されている．このように，メンバのパラメタとリーダへのオペレータの割り当てによって，温度データを収集し平均値を取るというデータフローを表現可能であると同時に，グループの構成や通信などのパラメタによってグループの，ネットワーク上での動作も表現可能である．

図 3.6: Group-levelモデルの記述例

3.2.3 Node-level DSML

Node-level DSMLは，個々のノードの動作を表現するためのDSMLとして定義

した．3.2.3節で述べたとおり，WSNアプリケーションは，最終的には個々のセンサノード上で実行される．よって，この個々のノードに割り当てられる役割を表現するためのDSMLを定義している．

個々のノードが担う役割を表現するためには，物理的なノードを表す概念と，

ノードに割り当てられる役割を表す概念が必要である．また，ノードに割り当てられる役割は，Group-level DSMLで表現されるノードグループの動作を詳細化したものであるためであるため，データの収集地点となるベースステーションとしての役割，データの操作と中継を担うリーダとしての役割，データの生成を担うメンバとしての役割の3種類が必要となる．更に，各役割がどの様な処理を実現するかを表現するため，データの計測，操作，送受信といったタスクが必要である．

図3.7がNode-level DSMLのメタモデルである．物理的なノードはNodeとして，ノードに割り当てられる役割はRoleとして定義されている．前述の3種類の

(22)

役割はそれぞれBaseStationRole，LeaderRole，MemberRoleに対応する．また，

各Roleが担う処理であるタスクは，データ計測はSamplingTask，データ操作は OperationalTask，データ送信はSendingTask，データ受信はReceivingTaskに対応している．これにより，各ノードの動作が，ノードに割り当てられるRoleと，

そのRoleが担う各種タスクとして表現できる．

図 3.7: Node-level DSMLのメタモデル

Node-level DSMLを用いて前述の室内温度計測アプリケーションのモデルを記

述した例が図3.8である．図3.8は，実際の環境には4つのセンサノードと1つのホストコンピュータに接続されたベースステーションノードが存在するという想定に基づき記述している．この図から，アプリケーション内にはBaseStationRole，

LeaderRole，MemberRoleが各1つずつ存在することがわかる．BaseStationRole は温度データの受信を，LeaderRoleは温度データの受信，受信した温度データへの平均値計算処理，ベースステーションへの送信処理を，MemberRoleは温度データの計測とリーダへの送信処理を担っている．また，BaseStationRole，LeaderRole はそれぞれ1つのセンサノードに，MemberRoleは3つのセンサノードに割り当てられることが見て取れる．このようにNode-level DSMLでは，アプリケーションを実現するために必要な役割と，各ノードがどの役割を担うかを表現できる．

(23)

図 3.8: Node-levelモデルの記述例

3.3 変換規則の設計

本節では，要件1と3を満たすために定義したDSMLで記述されたモデル間の自動変換を実現するための変換規則について詳述する．プロトタイプ開発時に

Dataﬂow-level DSMLを用いた場合，実装を生成するためには，ノード間の通信方

式，個々のノードへの役割の付与などを決定する必要がある．これらの決定の為に工数を割くことはプロトタイプ開発の遅れにつながるため，定義した変換規則ではこれらの決定事項に対し初期値を与えている．この初期値により決定をのちの品質調整時まで保留し，少ない工数での実装の自動生成を可能とし，要件1を達成している．また，品質調整時にGroup-level DSMLやNode-level DSMLを用いる場合，Dataflow-level DSMLでモデルを記述する際の決定事項が正しく受け継がれた Group-level，Node-levelのモデルが必要となる．この際，人手でDataflow-levelのモデルに対応するGroup-level，Node-levelのモデルを作成する場合，誤りが混入する恐れがある．そのため提案する開発プロセスでは，抽象度の高いDSMLで記述されたモデルから，抽象度の低いDSMLで記述されたモデルの自動生成を行う．このモデルの自動生成を実現するためにDataflow-levelからGroup-level，Group-level

からNode-levelへのモデル変換規則を定義した．この自動変換によりプロトタイ

プ開発時の成果物を，品質調整時にも再利用することが可能となり，要件3が満たされる．．これらプロトタイプの早期開発と成果物の再利用を実現するため，定義

(24)

表 3.1: Dataﬂow-level DSMLの要素からGroup-level DSMLの要素への対応付け

Dataﬂow-level DSMLの要素対応するGroup-level DSMLの要素

class attribute class attribute

DataSource dataType MemberNodes dataType

samplingCondition samplingCondition

transmissionCondition transmissionCondition

location Group locationCondition

AggregationPoint function Operator function

inputDataType AggregationOperator inputDataType TemporalAggregationPoint timeWindow TemporalAggregationOperator timeWindow

duration duration

FusionPoint function Operator function

inputDataTypes FusionOperator inputDataTypes

outputDataType outputDataType

した自動変換規則には各モデルに含まれる要素を対応付ける規則と，抽象度の低いモデルに新たに現れる情報に対して固定値を与える規則の2つが含まれている．

3.3.1 Dataflow-level モデルから Group-level モデルへの変換規則

まず，Dataﬂow-level DSMLに存在する要素からGroup-level DSMLに存在する要素への対応付けについて述べる．データフローを構成する要素はデータソース，

集約処理，融合処理の2つを含む中間処理地点，データシンクとこれらの関連を表すリンクであった．変換規則では，1つのデータソースは1つのグループに対応付けられ，データソースを実現する処理はグループ内のメンバに割り当てられる．

あるデータソースとリンクを持つ集約処理地点を実現する処理は，当該データソースに対応するグループのリーダにオペレータとして割り当てられる．また，融合処理地点は，融合処理のオペレータを持つリーダを含む独立したグループとして対応付けを行う．データシンクを実現する処理はリーダの特化であるシンクに対応付けられる．モデル上での具体的な対応付けについては，表3.1にまとめる．

Group-level DSMLに新たに現れる要素へ与える固定値については表3.2にまとめた．通信については，グループ内ではツリー型のトポロジを用いて通信し，圧縮や暗号は行わない．また，グループリーダ・メンバの選択については，リーダの指定はせず，WSN全体をメンバとして用いるものとしている．集約・融合といったデータに対する処理はネットワーク内で行うものをデフォルトとした．

この変換規則に基づいて実施したモデルの自動変換例を図3.9に示す．変換対象としたモデルは図3.4に示した室内温度取得アプリケーションである．このモデルは1つのデータソースと，これにリンクを持つ集約地点を持つ．これらは図3.9にて青線で示されるように，それぞれ1つのグループのメンバ，リーダに対応付けされている．また，Group-levelモデルに新たに現れる要素に対しては，赤線で示す

(25)

表 3.2: Group-level DSMLに新たに現れる要素と変換規則が与える固定値新たに現れる要素変換規則で与える固定値

グループ内ネットワークトポロジツリー型トポロジ (TREE) 通信方式：圧縮なし(NONE)

通信方式：暗号化なし(NONE) リーダ選択条件なし(ANY) メンバ選択条件すべて(ALL)

各種操作(集約・融合処理)を行う場所ネットワーク内(LeaderNodeへ割り当て)

ように，表3.2で挙げた初期値を各パラメタに対し与えている．このようにして，

Dataﬂow-levelモデルが持つ情報を対応付けつつ，足りない情報を自動で付与する

変換規則により，Group-levelモデルの自動生成を実現する．

Dataflow‐level Group‐level

: DataSink inputDataType = TEMPERATURE

function = AVERAGE : SpatialAggregationPoijnt

location = ROOM1 transmittingCondition = 30sec samplingCondition = 30sec dataType = TEMPERATURE

: DataSource

locationCondition = WHOLE topology = TREE

: Group

: Sink

locationCondition = ROOM1 topology = TREE

: Group

selectionPattern = ANY : LeaderNode

transmittingCondition = 30sec samplingCondition = 30sec dataType = TEMPERATURE selectionPattern = ALL

: MemberNodes

function = AVERAGE

inputDataType = TEMPERATURE : SpatialAggregationOperator

encryption = NONE compress = NONE : Communication

: mapping : adding

図 3.9: Dataﬂow-levelモデルからGroup-levelモデルへの自動変換例

3.3.2 Group-level モデルから Node-level モデルへの変換規則

Group-levelモデルからNode-levelモデルへの変換において，対応付けの概要は以下のとおりである．Group-level DSMLでは，グループの構成要素はリーダとメンバであり，リーダの特化としてシンクとリーダノード，メンバの特化としてメンバノードと，更に下位に位置するグループが存在した．変換規則では，シンク，リーダノード，メンバノードを実現する処理を，ひとつの役割とそれに付随す

(26)

表 3.3: Group-level DSMLの要素からNode-level DSMLの要素への対応付け

Group-level DSMLの要素対応するNode-level DSMLの要素

class attribute class attribute

Group topology Sending/ReceivingTask protocol

LeaerNode selectionPattern Role deploymentCondition

MemberNodes selectionPattern Role deploymentCondition

dataType SamplingTask dataType

samplingCondition samplingCondition

transmissionCondition SendingTask transmissionCondition

Operator function OperationalTask function

AggregationOperator inputDataType AggregationTask inputDataType TemporalAggregationOperator timeWindow TemporalAggregationTask timeWindow

duration duration

FusionOperator inputDataTypes FusionTask inputDataTypes

outputDataType outputDataType

Communication compress SendingTask compress

encription encription

るタスクとして対応付けている．また，リーダ・メンバ間で行われていた通信は，

データの送信タスク，受信タスクとして分割して対応付けている．Group-levelか

らNode-levelへのモデル変換における要素間の対応関係をまとめたものが表3.3で

ある．

Group-levelモデルからNode-levelモデルへの自動変換を実現するためには，表 3.3に示す対応関係に加えて，ネットワーク内のどのノードにどの役割を割り当てるかを決定する必要がある．定義する変換規則では，このノードへの役割の割当を，プログラムを配備するネットワークの情報を用いることで実現する．ネットワークの情報とは，ネットワーク内に存在する各センサノードのID，位置，任意の各種プロファイルを指す．本研究における変換規則では，このネットワーク情報を用い，Group-levelモデルのLeaderNode，MemberNodesの持つselectionPattern のパラメタに基づいてNode-levelモデルにおけるNodeへのRoleの割り当てを行う．ただし，BaseStationRoleは，自動でIDの最も小さいノードに割り当てることとしている．すなわち，Group-levelからNode-levelへのモデル変換では，変換

元となるGroup-levelのモデルとプログラムを配備するネットワークについて情報

を入力とし，変換後のNode-levelのモデルを出力する．

3.3.1節と同様，図3.10に，室内温度取得アプリケーションを対象とした自動

変換のイメージ図を示す．変換前のGroup-levelモデルにはSink，LeaderNode，

MemberNodesが各1つずつ存在するが，これらの要素はそれぞれBaseStationRole，

LeaderRole，MemberRoleへと対応付けられる．更に，各Roleが持つTaskは，元と

なるGroup-levelの要素が持つ属性，関連のあるオブジェクトに基づき生成される．

例えば，図3.10において，Group-levelモデルにおけるMemberNodesを実現する処理は，Node-levelモデルにおいてMemberRoleに対応付けられている．この対応付けの詳細を図3.11に示す．この際，MemberRoleに付随するタスクは，MemberNodes

(27)

が持つ属性と，MenberNodesと関連を持つCommunicationの情報に基づき生成されている．また，Node-levelモデルにて，生成されたRoleとネットワークに存在するNodeとの関連は，LeaderNode及びMemberNodesのもつselectionPattern 属性に基づき決定される．図3.10においては，まずは最もIDの小さいノードに BaseStationRoleが割り当てられる．その後，LeaderNodeの選択はいずれのノードでも良いため，適当なノード1つと関連が自動生成される．また，MemberNodes の選択条件は全てのノードであるため，残りのすべてのノードとの間に関連が引かれる．このように，Group-levelモデルが持つ処理をRoleとそれに付随するTask として切り出し，個別ノードへの割り当てを自動で行う事により，Node-levelモデルの自動生成を実現する．

Node‐level Group‐level

deploymentCondition = id == 0 : BaseStationRole

receiveDataType = TEMPERATURE protocol = CTP

: ReceivingTask

location = ROOM1 id = 2

: Node

deploymentCondition = ALL : MemberRole

samplingCondition = 30sec dataType = TEMPERATURE

: SamplingTask

encription = NONE compress = NONE transmissionCondition = 30sec sendDataType = TEMPERATURE protocol = CTP

: SendingTask location = ROOM1

id = 1 : Node

memberIds = {2, 3, 4}

deploymentCondition = ANY : LeaderRole

encription = NONE compress = NONE transmissionCondition = 30sec sendDataType = TEMPERATURE protocol = CTP

: SendingTask

: Node

: Node function = AVERAGE

inputDataType = TEMPERATURE : SpatialAggregationTask

receiveDataType = TEMPERATURE protocol = CTP

: ReceivingTask location = ROOM1

id = 0 : Node

locationCondition = WHOLE topology = TREE

: Group

: Sink

: Group

transmissionCondition = 30sec samplingCondition = 30sec dataType = TEMPERATURE selectionPattern = ALL

: MemberNodes

function = AVERAGE

inputDataType = TEMPERATURE : SpatialAggregationOperator

encryption = NONE compress = NONE

: Communication

: mapping : adding

図 3.10: Group-levelモデルからNode-levelモデルへの自動変換例

(28)

: Group

transmissionCondition = 30sec samplingCondition = 30sec dataType = TEMPERATURE selectionPattern = ALL

: MemberNodes

: Communication

deploymentCondition = ALL : MemberRole

samplingCondition = 30sec dataType = TEMPERATURE

: SamplingTask

encription = NONE compress = NONE

transmissionCondition = 30sec sendDataType = TEMPERATURE protocol = CTP

: SendingTask

Node‐level Group‐level

: mapping

図3.11: Group-levelにおけるMemberNodesからNode-levelにおけるMemberRole への対応付け例

(29)

3.4 開発プロセス中の各フェイズの詳細

本開発プロセスは，大きく分けて2つのフェイズからなっている．ここでは各フェイズにおける開発の流れを詳述することで，本開発プロセスを用いた場合の開発者の行うべき工程，システムにより自動でサポートされる工程を明示する．

3.4.1 プロトタイピングフェイズ

このフェイズは，機能要求からDataﬂow-levelのモデルを作成し，プロトタイプを実装を得るという流れのプロセスから成る．このプロセスを図示したものが図 3.12である．この図中において，上部のプロセスは開発者視点での開発プロセスであり，下部の枠で囲われたプロセスは自動変換器により実現される部分である．

: Functional Requirement

<<manual>>

<<process>>

Dataflow-level Modeling

<<physical>>

: Dataflow-levelModel <<automatic>>

<<process>>

Transformation

<<physical>>

: ApplicationCode

<<physical>>

<<automatic>>

<<process>>

TransformationRule

<<physical>>

: Group-levelModel

<<automatic>>

<<process>>

TransformationRule

<<physical>>

: Node-levelModel

<<automatic>>

<<process>>

Rule

<<physical>>

: ApplicationCode

図 3.12: プロトタイピングフェイズ中の開発プロセス

プロトタイピングフェイズにおいて，まず開発者は機能要求に基づきアプリケーションに必要なデータフローを決定する．WSNアプリケーションを通して取得したい物理世界の状況を同定し，望む状況を知るためにはどのような計測データが必要か，計測データに対してどのような処理が必要かを定めデータフローを作成する．このデータフローを，Dataﬂow-level DSMLを用いて記述，モデル化する．

この際，Dataﬂow-level DSMLでは計測間隔や計測場所といった情報も記述する必要がある為，開発者はどの程度の間隔でデータが必要か，特定の場所に関する計測を行うかといった事項も決定する．モデル作成後は，このモデルを自動変換器に入力として与えることにより，開発者はプロトタイプの実装を得ることができる．すなわち，プロトタイピングフェイズにおいて開発者が手動で行うプロセスは

(30)

Dataﬂow-levelのモデルの作成のみであり，ネットワークに非依存なデータフローのみを考えるだけで，自動でプロトタイプが得られる．

プロトタイピングフェイズにおける開発の具体例として，3.2節で述べた室内温度を取得するアプリケーションの場合を考える．このアプリケーションでは，室温という物理世界の状況を取得するためには温度データが必要となること，部屋全体の平均的な温度を知るために各センサノードの計測値に対し平均値を求めるという集約処理が必要となることを分析し，図3.3に示すデータフローが必要となることを決定する．その後，高頻度で室温を得る必要はないこと，特定の部屋のみの温度を取得したいこと等を要求に基づき分析し，図3.4に示すモデルを，Dataﬂow-level DSMLを用いて作成する．

自動変換器では，Dataﬂow-levelのモデルを入力とし，プロトタイプの実装を出力する．この過程において，自動変換器はGroup-level，Node-levelの各レベルにおけるモデルも自動で生成する．これらのモデルには，Dataﬂow-levelのモデルには含まれない情報が含まれるが，それらの情報は3.3節で述べたように変換規則で補われる．自動生成されたモデルはのちのチューニングフェイズにて品質調整の際に再利用が可能であり，スクラッチから各レベルのモデルを記述する手間を低減している．

3.4.2 _{チューニングフェイズ}

このフェイズは，プロトタイプの実行結果とデータ品質への要求から決定された設計上の変更を，任意のDSMLを用いてモデルを修正することで反映し，品質調整を施した実装を得る，という流れのプロセスから成る，このプロセスを図示したものが図3.13である．図中で枠に囲われたプロセスがチューニングフェイズの開発プロセスに当たる．枠外のプロセスは，データ品質への要求とプロトタイプの実行結果の分析を行い，どの品質を調整する必要があるか，そのためにはアプリケーションの設計上どのような変更を施す必要があるかを決定するプロセスを表している．本論文ではこの分析に関するプロセスについてのサポートは提案していない．また，枠内のプロセスにおいて，点線より上部のアクティビティが開発者の行うアクティビティ，点線より下部のアクティビティがシステムが担うアクティビティである．

チューニングフェイズでは，事前にどのレベルのモデルに対しどのような修正を加えるかが決定しているものとし，まず開発者がこの情報を元にモデルの修正を行う．この際，モデルの修正はDataﬂow-level，Group-level，Node-levelのいずれのモデルに対しても行うことができる．すなわち，プロトタイプ開発時に決定したデータフローに関する修正だけでなく，個々のノードへの詳細な修正を加えることや，個々のノードに分散する修正をノード集合への修正としてまとめて変更することも可能である．モデルへ修正を加えた後には，自動変換器に修正済みのモデルを入力として与えることにより，開発者は品質調整済みの実装を得るこ