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

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

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

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

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

するノード，データを集計するベースステーションノードで構成される．対象とし た患者数は46人であり，18個の中継ノードと1つのベースステーションノードを 配備し，実運用時間は41日を超えている．アプリケーションの実装はTinyOS上 でノードプログラミングを用いて行われている．各ノードは患者ノード，中継ノー ド，ベースステーションノードのいずれに当たるかが決定され，この種別に応じて タスク割当が行われている．WSNを設置し，アプリケーションを実行する環境は 病院内であり，屋外に比べ容易に電源が確保できるため，データ中継を担うノー ド，ベースステーションノードには電源が供給されているものとしている．そのた め，電力資源に対する制約は患者が持つノードに対してのみ存在するものとして いる．また，患者はセンサノードを持ったまま院内を自由に移動するため，計測・

送信を担うノードについては移動性を持つものとしている．[9]では，ルーティン グプロトコルとしてCollection Tree Protocol(CTP)[14]を採用している．CTPと は，TinyOSによりサポートされている，ツリー型のトポロジによりデータ収集を 行うプロトコルである．しかし，特に移動性を持つ患者のノードと中継ノード間で の通信について，CTPでは通信の信頼性が低く，データ欠損率が高いという課題 を解決するため，Chiparaらは患者ノードと中継ノードとの間の通信に，Dynamic Relay Association Protocol(DRAP)という専用の通信プロトコルを設計，実装し 用いている．

このアプリケーションにおけるデータフローは，センサデータの計測に関する決 定から，Dataflow-levelモデルとして図4.5のように表現できる．当該アプリケー ションは2種類のデータを計測，送信するのみであるため，図4.5の様なモデルと なる．[9]では収集したデータを身体の異常を検知するアルゴリズムの入力として 用いることも考えているが，この様な変更にも，図4.5のDataSourceとDataSink の間にFusionPointを追加することで対応可能である．このDataflow-levelモデ ルからプロトタイプの自動生成が可能なため，前節で示した開発と同様，この開 発においても要件1が満たされているといえる．

図 4.5: 患者状態監視アプリケーションのDataflow-levelモデル例

前述のように，当該アプリケーションは患者ノード，中継ノード，ベースステー

ションノードの3種類のノードからなり，各種ノードはそれぞれ異なるタスクが 割り当てられる．このタスク割当は，本開発プロセスでは Group-levelモデル，

Node-level モデルの双方で表現可能である．また，4.1.1節の場合と同様，タス

ク割当の決定はプロトタイプ開発時に自動生成されたモデルに対する変更とし てモデルに反映する．Group-levelモデルを用いた場合，タスク割当はモデル上 のLeaderNode，MemberNodesの配置条件として表現できる．3.3.2節で示したと おり，Group-levelモデルからNode-levelモデルへの自動変換の際のノードと役 割の割り当て関係は，Group-levelモデルにおけるLeaderNode，MemberNodesの 配置条件とWSNを構成するのノード情報を含むネットワーク情報に基づき行わ れる．本ケースでは，まずネットワーク情報に含まれるノード情報に，各ノード が患者，中継，ベースステーションノードのいずれであるかを表す”TYPE”という 属性と”PATIENT”，”RELAY”，”BASESTATION”という対応する値を与えた．更に，

Group-levelモデルにて，自動生成されたモデルではLeaderNode，MemberNodesの deploymentConditionの値が”ANY”，”ALL”であったところを，それぞれに”TYPE

== RELAY”，”TYPE == PATIENT”に変更した．これにより，計測・送信に関するタ スク，中継に関するタスクの割り当てを，ひとつの条件式として表現可能である．

このネットワーク情報とモデルの変更を図4.6に示す．Node-levelモデルを用いた タスク割当は，4.1.1節の場合と同様，ノードと役割との間の関連を変更すること で実現可能である．この変更の様子を示したものが図4.7である．自動生成された モデルでは適当なノード一つに中継ノードとしてのタスク，残りの全てのノード に患者ノードとしてのタスクが割り当てられているところを，IDに応じて適切な タスクの割り当てるよう関連を変更している．

図 4.6: 患者状態監視アプリケーションのGroup-levelモデルに対する再設計

図 4.7: 患者状態監視アプリケーションのNode-levelモデルに対する再設計

また，図4.7の修正後のモデルは，図4.6の修正後のモデルとネットワーク情報か ら自動生成されるモデルに等しい．Node-levelモデルを直接変更した場合には，モ デルへの変更箇所が複数のノード・役割間の関連に分散するところを，Group-level モデルを変更した場合には変更箇所がリーダ，メンバの配置条件に集約されてお り，かつ得られる結果は同じであるといえる．

更に，当該アプリケーションでは，プロトタイプの実装ではCTP用い，実行結 果から患者ノードと中継ノード間のルーティングプロトコルを変更している．す なわち，通信方式の変更という再設計を実施することで品質調整を行なっている．

この様な変更についても，Node-levelモデルにて，Sending/ReceivingTaskのプ ロトコルのパラメタを変更することで，モデル上に設計の変更を反映可能であっ た．ただし，独自のプロトコルを用いる場合には別途プロトコルの実装を用意す る必要がある．このように，患者状態監視アプリケーションの開発においても通 信方式や役割，タスク割り当ての変更が可能であり，これらの変更はプロトタイ プから自動生成されたモデルに対して行えるため，要件2，3を共に満たしている．

その他，表4.1に挙げたアプリケーションについても同様に検証を行ったところ，

データフローからのプロトタイプ生成，通信方式やタスク割り当ての変更による 品質調整が実現可能であった．品質調整時には，プロトタイプ生成時に同時に自 動生成されたGroup-level，Node-levelのモデルを再利用可能であることも確認し た．ただし，幾つかのアプリケーションにおいて，一部機能や品質調整項目は記 述不可能であるという結果を得た．これについては4.2節にて詳述する．