(57)【要約】【課題】空間コンピューティングアプリケーションを記述するタスク割当方法を提供する。【解決手段】アブストラクトタスクグラフ（ＡＴａＧ）２００を生成し、そのアプリケーションを実行するノードの個数、配置及び相互接続性にふれることなくアプリケーションの動作を指定する。タスクはネットワークに対して自動的にマッピングする。ＡＴａＧは一組のタスク２１０，２２０，２３０，２４０、一組のデータオブジェクト２１５，２２５，２３５及び一組のチャネル２４５，２５０，２５５，２６０，２６５，２７０を指定する。ネットワーク内タスク実行個所、場所間データ移動形態及び各所所要データに関する各種の制限事項や所望事項２８０，２９０を盛り込める。【選択図】図２
2006146917.tif 000002
【特許請求の範囲】
【請求項１】
一組のタスク、一組のデータオブジェクト及び一組のチャネルを含むアブストラクトタスクグラフを生成するステップと、
タスクをネットワークノードに割り当てるステップと、
それらタスク、データオブジェクト及びチャネルに係る通信をそれらノード同士で実行させるステップと、
を有するタスク割当方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は概略にはコンピュータネットワークに関し、より詳細にはアーキテクチャ非依存（インディペンデント）プログラミングによる空間分散ネットワークの合成に関する。
【背景技術】
【０００２】
特許文献１に記載のプログラム生成方法においては、データ宣言及びデータ使用形態に関連付けられた入力が与えられると、そのデータ宣言に基づき既設のプログラム部品雛型ライブラリ内のプログラム部品雛型が個々にカスタマイズされ、そのデータに対し適切な変換を施せるプログラム部品が生成される。この方法は、基本的には、指定された構造化データに対する変換関数乃至変換メソッドの自動生成に利用されるものである。
【０００３】
特許文献２に記載の方法においては、センサノード上で動作する１個、ゲートウェイ上で動作する１個、サーバ上で動作する１個をあわせ３個のユニットを有するアプリケーションソフトウェアが生成される。この方法にて基本としているのは、それら３個のユニットを構造的に同一又は同質のものとしておき、パラメータ設定によって幾分カスタマイズして使用すればよい、という考え方である。この方法においては、更に、センサノード上のユニットがゲートウェイ上のユニットに情報を送り、これを受けたゲートウェイ上のユニットがサーバ上のユニットに情報を送る、という固定的なやり方でこれら３個のユニット同士がやりとりを行うことも、前提とされている。これらユニットそれぞれを構成する一組のコンポーネントは、その動作をパラメータにより設定可能で、且つ同一ノード上にあるコンポーネント同士が通信しあえる仕組みを有するものである。この文献には、また、所与コンポーネントについてのライブラリをそのユーザに提示するグラフィカルインタフェースも記載されている。更に、シェルと呼ばれる注釈には、そのコンポーネントの名称及び機能だけでなく、そのコンポーネントのパフォーマンス上の特徴、例えばメモリ使用量、コードサイズ等が含まれている。従って、あるアプリケーションユニットの構築に使用されたコンポーネントについて、こうしたシェル内の情報を分析することによって、そのユニットのパフォーマンス上の特徴を判別することができる。
【０００４】
特許文献３に記載の自動プログラムシンセサイザは、所与の仕様入力形式に従い入力されるシステム仕様に対しそのサブシステム群を適用することによって、目的とするプログラムを生成する。この目的プログラムの仕様は仕様入力形式に従い詳細に記述しておく。また、変数名及びその意味のリストが変数属性管理システムによって保存されており、プログラム生成手段は、変数属性管理システムとのやりとりを通じて変数名を取り出し、取り出した変数名を使用して目的プログラムを生成する。ユーザはプログラム最終生成より前の段階でそのプログラムを編集することができる。例えば未定義変数発生時である。
【０００５】
特許文献４に記載の方法は、複数個のプログラムコンポーネントを組み合わせてより大規模な新規プログラムを生成する方法であり、そのインタフェース間が整合していないプログラムコンポーネント群にも適用できる。この方法においては、不整合インタフェースペア間変換ルール及び不整合データ仕様ペア間変換ルールが蓄えられており、整合していない２個のインタフェースを一致させたいときには、調停プログラムジェネレータにてそれら変換ルールを用いて調停プログラムを生成する。この調停プログラムは、それら整合していないインタフェース間の通信を取り扱うプログラムである。
【０００６】
なお、上記各特許文献による開示の内容については、この参照を以てその全体を本願中に繰り入れるものとする。
【０００７】
【特許文献１】米国特許第４９４９２５３号明細書
【特許文献２】米国特許出願公開第２００４／６７６１号明細書
【特許文献３】米国特許第５０３８２９６号明細書
【特許文献４】米国特許第５３１５７１０号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００８】
現状のプログラミングツール及びプログラミング手法においては、ネットワークのカスタマイズや、そのネットワークの各ノードにより実行されるタスクタイプのカスタマイズは、通常、プログラマがやらねばならない仕事とされている。アーキテクチャ依存（ディペンデント）プログラミングにおいては、ソリューションの軽便性（ポータビリティ）や融通性・拡張性（エクステンシビリティ）を高めるのに限界がある。アーキテクチャ依存プログラミングには、また、アプリケーション領域だけでなくネットワーク領域でも知識・技能を積んだプログラマが必要であるため開発コストが嵩む、という問題もある。そのため、アーキテクチャ非依存プログラミングの魅力が高まっている。ネットワークプログラミングにおけるアーキテクチャ非依存性とは、抽象化されておりその構成がパラメータにより定められるネットワークアーキテクチャについて、アプリケーションの動作を指定すればよいことをいう。アーキテクチャ非依存性によってもたらされる明らかな利点としてはソリューションの軽便性がある。軽便性とは、別々のネットワーク構成要素に対して同種のアプリケーションを自動合成でき、またシステムノードのフェイル又は追加に対して当該アプリケーションを自動適合させられる、ということである。更に、アーキテクチャ非依存プログラミングを実現できれば、ネットワーク及びそのノードの設定（コンフィギュレーション）を最終決定する前に、そのアプリケーションの開発を進めることができる。
【課題を解決するための手段】
【０００９】
本発明の幾つかの実施形態に係るタスク割当方法は、一組のタスクをユーザ入力に応じてネットワーク内のどこで実行するかをアブストラクトタスクグラフ（abstract task graph:以下「ＡＴａＧ」）なる形態で決定するステップを有する。このＡＴａＧは、一組のタスク、一組のデータオブジェクト及び一組のチャネルを含むものであり、ネットワークの構成、使用状態及び設定から独立して指定される。
【００１０】
更に、本発明の幾つかの実施形態に係るタスク割当システムは、ＡＴａＧに基づきタスク及び通信チャネルの配分を動的に制御するコントローラを備える。このＡＴａＧは、一組のタスク、一組のデータオブジェクト及び一組のチャネルを含む。本システムは、更に、当該一組のタスクのパフォーマンスを制御し、当該データオブジェクト及びチャネルを用いてネットワークを設定するコントローラを備える。それらタスク、データオブジェクト及びチャネルはアーキテクチャ非依存性である。
【００１１】
更に、本発明の幾つかの実施形態に係るマシン可読媒体によって与えることができる命令には、ネットワーク設定を実行するための命令及び一組のタスクを実行するための命令が含まれる。ネットワーク設定命令をプロセッサに実行させると、そのプロセッサは、一組のタスク、一組のデータオブジェクト及び一組のチャネルを含むＡＴａＧに基づき、当該一組のタスクを実行させるべきネットワークのマッピングを実行する。タスク実行命令を実行させると、それらデータオブジェクト及びチャネルを用い当該一組のタスクがそのネットワーク内の対応するノード上で実行される。それらタスク、データオブジェクト及びチャネルはアーキテクチャ非依存性である。
【発明を実施するための最良の形態】
【００１２】
以下、本発明の幾つかの実施形態に係るシステム及び方法について、別紙図面を参照して詳細に説明する。
【００１３】
まず、アブストラクトタスクグラフ（ＡＴａＧ）とは、そのアプリケーションが実行されるネットワークのアーキテクチャから独立して（即ち当該アーキテクチャに依存せずに）所望アプリケーションの動作を記述するのに使用できるよう、定義されている表記である。本願中、「ネットワーク」及び「ネットワークアプリケーション」なる用語は、センサ網等、一般に、ネットワーク内でのデータアイテムの物理的な発生場所及び発生時刻がそのデータアイテムに関する処理にて重要な役割を有するシステムに関する用語として、使用されている。より一般的に表現すれば、本発明の幾つかの実施形態に係るシステム及び方法は例えば空間コンピューティングアプリケーションに関するものである。空間コンピューティングアプリケーションは、無線センサ網や都市内交通信号灯網等にて使用される。この種のアプリケーションに共通する特徴は、空間的に近い場所にあるコンピューティングノード間で処理を協調させることが実用上有意義である、という点である。
【００１４】
一般に、空間コンピューティングアプリケーションのアーキテクチャは複数個のパラメータを包含している。それらは時間経過により変化し、そのネットワーク構成要素毎に異なり、また事前計画時よりはむしろネットワークインストール中に決まるものである。そうしたパラメータとしては、例えば、ネットワーク内ノード個数、実座標系又は仮想座標系における各ノードの配置、ネットワークの相互接続性、各ノードにて利用可能なリソース等がある（但しこれらには限られない）。各ノードにて利用可能なリソースは一般に複数あり、それらの中には例えば計算リソース、記憶リソース（メモリ、ディスク等）、通信リソース（帯域幅、覆域等）、センシングリソース（利用可能なセンシングインタフェースの個数及び種類等）等が含まれ得る。
【００１５】
図１にネットワークの例１００を示す。この図に示されているネットワーク１００は、例えば、指定場所に指定個数のノードが配置されていて各ノードが一組の指定リソースを有する、といった個別的なアーキテクチャを有している。ネットワークアプリケーションのプログラミングや合成は極めてしばしばアーキテクチャ依存的になる。即ち、各ノード１１０により実行されるタスクのタイプが、そのネットワーク１００のアーキテクチャに応じてカスタマイズされることとなる。
【００１６】
データ駆動方式を適用すれば、アーキテクチャ非依存的にネットワークプログラムを作成する、という目的を達成することができる。データ駆動方式は非フォン・ノイマン方式の一種であり、この方式においてはオペランドに対する演算が可能になったらそのオペランドに対する所要演算が実行される。通常、データ駆動方式用の計算プログラムは有向グラフによって表される。有向グラフにおいては、データフローが各線（エッジ）によって、そのデータに対する所要計算タスクが各接点乃至頂点（バーテクス）によって、表される。このグラフに即していうと、データ駆動方式とは、あるタスクに対応するバーテクスの入力エッジにおいて、そのバーテクスにて使用するデータアイテムが全て整ったら、そのバーテクスに対応する命令乃至タスクが実行可能になる、という方式である。命令乃至タスクを実行する際には、そのバーテクスにおいて、各入力エッジからデータトークンを一つずつ取り込んで出力エッジから出力トークンとしてリリースする。こうした基本的なデータフローモデルの他にも、変形を施したデータフローモデルが多様に開発されており、それらについては研究論文等から知ることができる。
【００１７】
一般に並列分散計算システムにてデータ駆動方式によるプログラミングモデルが魅力的とされるのは、エンドユーザによるプログラミングに便利だからである。即ち、入力オブジェクト及び出力オブジェクトだけでタスクを指定でき、且つそのタスクの実行、スケジューリング及び通信を全て基本ランタイムシステムが管理するのであれば、エンドユーザたるプログラマはより上位階層のアルゴリズム設計及び最適化に集中できる。更に、データ駆動方式ではあるタスクが直接に別のタスクを呼び出すことはなく、むしろ、あるタスクによってオブジェクト乃至トークンが生成されるとそうしたトークンに関わりを持つ別のタスクが起動される。このようにタスクとタスクとのつながりを抑えてある（タスクインタフェース同士を分離してある）ため、アプリケーションをモジュール化することができ、且つ融通性・拡張性が高いアプリケーションとすることができる。
【００１８】
ネットワーク型空間コンピューティングアプリケーションにてデータ駆動方式を用いる目的乃至利点は二通りある。第１に、データ駆動方式を用いることによって上位階層でのネットワーク内プロセス間協調を単純且つ直感的に表現できる。第２に、データ駆動方式用のプログラムは通常は能力の高いランタイムシステムによりサポートされるため、当該ランタイムシステム内にリソース使用に関わる様々な最適化を採り入れ、アプリケーション作成に当たりアプリケーション開発者がその種の最適化を懸念又は課題視する必要をなくすことができる。
【００１９】
データ駆動方式によるプログラミングモデルをネットワークプログラミングにて使用することの利点は、意味が直感的に分かる方式であること及び複雑性を抑えられることの二つであり、特にセンサアクチュエータ網にて使用される種類の空間コンピューティングアプリケーションにてそうである。その種のアプリケーションにおいては、ネットワーク内処理のほとんど全てが、処理できるデータが存在しているときに又はそのデータの性質（値）に応じて起動される。従って、処理タスクはデータオブジェクトに施す演算によって自ずと規定される。各タスクのインタフェースを他のタスクのインタフェースから分離させてあるため、そのタスクが実行されるノード又はそれと隣接するノード上で実行される他のタスクの状態如何によらず、各タスクをタスク毎にまた指定されたデータオブジェクトによって起動させることができる。そのため、どのようなデータオブジェクトを提供及び使用するかにより規定されるタスクインタフェースを同一に保つ限りにおいてであるが、ユーザは各タスクについて個々のパラメータを自在に変化させることができ、更にはタスク実装形態を変更させることができる。それによって他のタスクに影響が及ぼすこともない。更に、通常、ネットワークアプリケーション開発上最も面倒なのは制御動作及び協調動作が複雑な場合であり、そういった複雑性の大部分は各種ネットワークプロトコルの細部に起因している。アプリケーション仕様を記述する際にデータ駆動方式によるプログラミングモデルを使用することにより、この種の複雑性は大部分プログラマから隠すことができる。それは、制御動作及び協調動作の細部がほとんど全てランタイムシステムにより管理されるためである。
【００２０】
図２にＡＴａＧの例２００を示す。ＡＴａＧ２００を用いることによって、アプリケーションの動作をアーキテクチャ非依存的に指定でき、また、ネットワーク内での処理及びデータ転送の一般的性質を特定の構成要素とリンクさせることなく記述することができる。ＡＴａＧ２００をアブストラクト即ち抽象図表と称しているのは、このＡＴａＧ２００を指定ネットワーク上でコンパイルしたとき、各種タスクのインスタンス（instance:構造体）の個数、タスク配置、各種データオブジェクトのインスタンスの個数、データ通過経路、データ転送用ネットワークプロトコル等が自動的に決定されるためである。ＡＴａＧ２００は、例えば、（ｉ）一組のタスクと、（ｉｉ）一組のデータオブジェクトと、（ｉｉｉ）各タスクを１個又は複数個のデータオブジェクトと関連付ける一組の注目チャネルと、を含む構成とする。
【００２１】
例えば、それぞれ温度センサが１個ずつ設けられた複数個のセンサノードによってセンサ網を形成したとする。この種のセンサ網向けの最も単純なアプリケーションとしては、例えば次のような全体動作を目指したアプリケーションを作成することができる。即ち、（ｉ）各センサノードが周囲温度を３０分毎に１回サンプリングしその結果である温度計測値を指定ルートノードに送る、（ｉｉ）各センサノードが自分のところで計測した温度即ちローカル温度を各１ホップ隣接ノードにて計測された温度と１０分毎に１回比較しもし摂氏目盛で５°を上回る相違が検出されたら警報通知を指定ルートノードに送る、というアプリケーションである。
【００２２】
ここに、ノードｙがノードｘの無線覆域内にある場合ノードｘはノードｙの１ホップ隣接ノードであるという。「無線覆域」という規定が意味をなすのは有限な通信範囲を有する無線送受信機を用いてネットワーク内通信を行う場合であり、有線インフラストラクチャを用いて通信を行うネットワークや有線インフラストラクチャ及び無線インフラストラクチャを併用して通信を行うネットワークにおいては、通信媒体の性質に応じて「ホップ」を定義するのが適当である。空間コンピューティングに係る実施形態においては、例えば、「ホップ」をノード間の空間的距離の関数として定義し、ノードｙがノードｘから所定距離以内にあればノードｘがノードｙの１ホップ隣接ノードであるとする。また、ノードｚがノードｙの無線覆域内でノードｘの無線覆域外に存している場合、そのノードｚはノードｘの２ホップ隣接ノードであり且つノードｙの１ホップ隣接ノードであるという。あるノードのｋホップ隣接範囲とは、そのノードから最大ｋホップで到達可能な全ノードの集まりをいう。更に、そのアプリケーションに特徴的なトポロジ、例えばｋ平均法クラスタリング（k-mean clustering）やデローニー三角形分割（Delaunay triangulation）によるトポロジがある場合は、それに基づいて「ホップ」を定義することもできる。
【００２３】
こういったアプリケーションをＡＴａＧ２００を用いて記述する方法は複数通りある。次にその一例を述べる。
【００２４】
ここではまず４種類のタスクを定義する。即ち、標本化タスク２１０、ルート収集タスク２２０、隣接ノード監視タスク２３０及び警報発動タスク２４０である。
【００２５】
この例においては、標本化タスク２１０は、システムを構成する各ノードにて例えば３０分周期で周期的に実行され、実行のたびに温度センサインタフェースにアクセスして現在の温度を読み込む。隣接ノード監視タスク２３０は、システムを構成する各ノードにて例えば１０分周期で周期的に実行され、温度をサンプリングしてその結果を隣接ノード群に送る。隣接ノード監視タスク２３０は、更に、隣接ノードから最近に送られてきたメッセージ、温度計測値又はその双方を読み込み、それらを自分のサンプリング結果等と比較して、もしそれらの間の差が例えば摂氏目盛で５°を上回っていたら警報通知を発する。ルート収集タスク２２０は、ネットワーク記述中に含めねばならずネットワーク全体で１個しかないノード即ちルートノード上で、標本化タスク２１０から温度計測値を受信するたびに実行され、受信した温度計測値をスクリーン上に表示させる。そして、警報発動タスク２４０は、ネットワーク全体で１個しかないノード即ちルートノード上で、隣接ノード監視タスク２２０から警報通知を受信するたびに実行され、警報を発する。
【００２６】
この例においては、更に、何個かの抽象的なデータアイテムが規定されている。例えば、温度標本値データアイテム２１５は、標本化タスク２１０によって周期的にサンプリング（標本化）されルート収集タスク２２０に送られた温度計測値を表しており、局所勾配値データアイテム２２５は、隣接ノード監視タスク２３０間でやりとりされる温度計測値を表しており、警報事象データアイテム２３５は、隣接ノード監視タスク２３０から警報発動タスク２４０に送られる警報通知を表している。
【００２７】
この例においては異種タスク間に次のような入出力連携関係があることが分かる。まず、標本化タスク２１０には入力はないが温度標本値データアイテム２１５という一種類の出力があり、従って標本化タスク２１０を温度標本値データアイテム２１５に結び付ける１個の出力チャネル２４５がある。隣接ノード監視タスク２３０には局所勾配値データアイテム２２５という一種類の入力と局所勾配値データアイテム２２５及び警報事象データアイテム２３５という二種類の出力があり、従って隣接ノード監視タスク２３０を局所勾配値データアイテム２２５に結び付けるチャネルとして１個の入力チャネル２５０と１個の出力チャネル２５５があり更に隣接ノード監視タスク２３０を警報事象データアイテム２３５に結び付ける１個の出力チャネル２６０がある。
【００２８】
ルート収集タスク２２０には温度標本値データアイテム２１５という一種類の入力があるが出力はなく、従ってルート収集タスク２２０を温度標本値データアイテム２１５に結び付ける１個の入力チャネル２６５だけがある。警報発動タスク２４０には警報事象データアイテム２３５という一種類の入力があるが出力はなく、従って警報発動タスク２４０を警報事象データアイテム２３５に結び付ける１個の入力チャネル２７０だけがある。
【００２９】
注記すべきことに、あるタスクの出力が何らかのデータアイテムに割り当てられているからといって、必ずしも、そのタスクが呼び出される毎に必ずそのデータアイテムが発生するわけではない。例えば、隣接ノード監視タスク２３０にある種のコマンド（群）を組み込んでおくことにより、局所勾配値データアイテム２２５に係る計測値が許容範囲内なら警報事象データアイテム２３５が発生しないようにすることができる。
【００３０】
ＡＴａＧ２００を構成するエンティティであるタスク、データアイテム及びチャネルにはそれぞれ注釈することができる。例えばタスク注釈２８０には、そのタスクが周期性か非周期性かという性質上の違い、そのタスクが周期性であればその周期、そのタスクによるインスタンス化（instantiation:インスタンス乃至オブジェクト生成）密度等の情報を含めることができる。インスタンス化密度については、例えば、各ノードのタスクに１インスタンス、ノード１０個毎に１インスタンス、１平方マイル毎に１インスタンス、ルートとして指定されているセンサノードのみに１インスタンス、特定種類のリソースを使用できる各センサノードに１インスタンス、等と設定・記述することができる（なお１平方マイルは約２．５９ｋｍ２）。図２においては以上説明した例に即して注釈２８０が記述されている。この例では不要であるためデータアイテムに注釈していないが、データアイテムにもタスクやチャネルについてと同じく注釈することができる。
【００３１】
入力チャネルや出力チャネルへの注釈であるチャネル注釈２９０は、例えば、指定データアイテムに係るインスタンスのうちどのようなインスタンスにそのタスクが関わるのかを、示している。例えば、あるタスクの出力チャネルに「ローカル」とラベリングされている場合、そのタスクによって生成されるデータアイテムは、そのノードのローカルデータプールにのみ追加されるべきであって、生成後にネットワーク内の他のノードに積極的に送り出されるべきではない。同様に、出力チャネルに「１ホップ」とのラベリングがあれば、そのタスクによって生成されるデータアイテムは１ホップ隣接ノードに送られるべきである。入力チャネルに「全ノード」とのラベリングがあれば、その種のデータアイテムについてネットワーク内の各ノードによって生成されたインスタンスは全て、それらのインスタンスを使用するタスクのホストノードに送られるべきである。
【００３２】
センサノードに設けられているデータプールとは、概念的には、（ｉ）所定時点にそのノード上に存在している各種データアイテムのインスタンスを集めたもの（そうしたインスタンスの多くはそのノード上で実行スケジュールが組まれている１個若しくは複数個のタスクによる使用を待っているか又はネットワーク内の他のノードに処理対象として送信されることを待っている）ものであり、或いは（ｉｉ）それらインスタンスの記憶場所を示す情報を集めたものを指している。タスクによるデータオブジェクトの生成及び使用は、例えば、こうしたデータプールへのデータアイテムの追加又は当該データプールからのデータアイテムの削除としてモデリングされる。更に、通常このデータプールに対応して設けられるデータプールマネージャは、複数個のタスクによるそのデータプールへのアクセスを制御する、処理すべき種類のデータアイテムがそのデータプールに追加されたときにタスクの実行をスケジューリングする等の仕事を、担っている。
【００３３】
一つのタスクが同じデータアイテムを生成だけでなく使用もする場合は、そのノード上で同一タスクが無限ループ実行されることを防ぐため、特別な意味づけ（特別な仕組み）を設けるのがよかろう。例えば隣接ノード監視タスク２３０と局所勾配値データアイテム２２５の関係がこれに該当している。即ち、隣接ノード監視タスク２３０からの出力チャネルには「１ホップ」と注釈されているため、隣接ノード監視タスク２３０によって生成される局所勾配値タイプのデータアイテム２２５は、１ホップ隣接ノードだけに送られローカルデータプールには全く追加されない。このノードのローカルデータプールにも同タイプのデータアイテムのインスタンスが現れるけれども、それらは１ホップ隣接ノード上で実行された隣接ノード監視タスク２３０から送られてきたものである。
【００３４】
これまでの説明においては、特定のネットワーク構成要素にもネットワーク内ノード個数にもまたネットワークトポロジにも言及する必要がなかった。従って、同じＡＴａＧを各種ネットワークの設定に使用することができる。設定対象とし得るのは、ＡＴａＧにて指定された動作を実現するのに、例えば、ネットワーク内のどのノード上でどのタスクを実行させるべきか、ノードからノードへのデータアイテムの送信をどのようにして行えばよいか、といった事項である。
【００３５】
注記すべきことに、ＡＴａＧにおいては、ネットワーク内情報フローに共通に現れるパターン、ここでは空間的な情報分配及び収集のパターンを、注目チャネルに「１ホップ」「ローカル」「全ノード」等と簡単に注釈することによって、表すことができる。勿論、所要又は所望に従い、より洗練されたかたちで注釈するようにしてもよい。図示した例においては、例えば、ルート収集タスク２２０に対する温度標本値タイプのデータアイテム２１５の入力に、そのデータアイテム２１５の供給元が「全ノード」２９０であると注釈されている。このようにするだけでも、ランタイムシステムにて適切なネットワーク内データパスをセットアップし、必要なネットワーキングレベル協調コード全てを発生させるのに十分である。
【００３６】
図３に注釈付きネットワークグラフの例３００を示す。この図に示す注釈付きネットワークグラフ３００を用いることによって、目的とするネットワーク３３０におけるコンパイル処理用パラメータを指定することができる。指定したパラメータを使用しコンパイル処理を実行することによって、アプリケーション仕様を表しているＡＴａＧを、ネットワーク３３０の各ノード３７０上に実装されるランタイムシステムの動作を決定づける一組の設定ファイルへと、好適に変換できる。それによって、ＡＴａＧによって指定された所望の機能並びにユーザが作成するアプリケーションレベルタスクのコードを、実現することができる。
【００３７】
注釈付きネットワークグラフ３００はＧＵＩ（graphical user interface）等を用い様々な方法で作成できる。例えば、注釈付きネットワークグラフ３００には次のような方法で作成できる。（ｉ）第１の方法は、ネットワーク３３０を記述するグラフィカルオブジェクト３５０にノード３７０を記述するグラフィカルオブジェクト３５０を個別に追加し、各ノード３７０の所要パラメータを入力する、という方法である。（ｉｉ）第２の方法は、そのグラフィカル環境にて利用できるよう予めネットワーク記述ライブラリを作成しておき、そのライブラリからネットワーク記述を選択する、という方法である。（ｉｉｉ）第３の方法は、そのグラフィカル環境にて利用できるよう予めパラメータ式ネットワーク記述ライブラリを作成しておき、そのライブラリからネットワーク記述を選択し、所望に応じパラメータ値を変更してそのネットワーク記述をカスタマイズする、という方法である。なお、注釈付きネットワークグラフ３００はテキスト形式で記述作成することもできるが、より使いやすいものにしより見やすくするという観点からすれば、作成にグラフィカルインタフェースを使用できるようにした方がよい。
【００３８】
図４にネットワーク設計用ＧＵＩの例４００を示す。この図に示すＧＵＩ４００は、タスクアイテム４１０、データオブジェクト４３０及びチャネル４２０を決めるのに使用される。タスクアイテム４１０によって表すことができるのはネットワーク内で実行され得る処理がどのタイプかであり、タスクアイテム４１０だけでは、そのタイプの処理に係るインスタンスがそのネットワーク内に任意時点で何個存在することとなるかについては、定められない。各タスクには、一組の注釈、プログラマがそのタイプの処理に付ける論理名、データアイテム利用可能時に呼び出されるユーザ提供タスクコード等を、含め又は付することができる。タスクオブジェクトに対する注釈は、ネットワーク内のどこでいつそのタスクについてインスタンスが生成されるか等を管理するためのものであり、それによって例えばインスタンス化条件の種類を指定することができる。その種の注釈においては、何通りかの選択肢（値）の中からどれか適当なものをプログラマが必要に応じ１個又は複数個選択できるようにするとよい。例えば、インスタンス化条件の一つに「１タスク当たりノード個数」という種類がある。このインスタンス化条件に関係する注釈を作成する際には、ユーザは、インスタンス化密度を示すパラメータ値を与えなければならない。例えば１０という値を与えれば、センサノードのうち１０個当たり１個がこのタスクの１インスタンスをホスティングすることとなる。また、インスタンス化条件には他に「空間的条件」という種類がある。この種のインスタンス化条件についてユーザから与えるパラメータは、例えば、配置領域を指定する座標のリストである。そうしたパラメータを与えることによって、タスクは指定された配置領域内に存する各ノードにマッピングされることとなる。インスタンス化条件の種類としてはこれら以外の種類も規定でき、また複数種類あるインスタンス化条件を様々なやり方で組み合わせることもできる。例えば、「空間的条件」と「１タスク当たりノード個数」とを組み合わせて用いることによって、ネットワーク内の指定領域内だけで指定密度にてタスクがインスタンスを生成し他の領域ではインスタンス化が行われないようにすることができる。指定領域が十分狭ければ、ネットワーク内のある一つのノードだけでそのタスクに係るインスタンス化が行われることとなろう。
【００３９】
インスタンス化条件としては、この他、例えば「リソース利用可能性」等の種類を指定できる。リソースという用語がセンシングインタフェースについても使用されるものであることから分かるように、この種のインスタンス化条件によって、プログラマは、特定種類のセンシングインタフェースからデータを読み込むであろうタスクのうち、その種のインタフェースが実装されているノード上で実行されるタスクだけがインスタンス化を行うよう、指定することができる。
【００４０】
こうした抽象的なタスクオブジェクトに対する注釈としては、他に、発火（起動）ルール等に関する情報がある。発火ルールは、入力データオブジェクト４３０を利用できるタスクの実行スケジュールを指定するものである。例えば「周期的」と指定すればそのノードの寿命が続く限り指定頻度でそのタスクを実行させることができるし、「何れかでもデータが来たら」又は「全データが揃ったら」と指定すればそれぞれ入力アイテムが個別に到来すること又は全て揃うことを発火条件として規定することができる。ここで述べたような注釈をより多岐に亘り規定しまたネットワークアーキテクチャに応じ適宜解釈し直すようにしてもよい。
【００４１】
各データオブジェクト４３０には、例えば、（ｉ）アプリケーション特有のデータ構造を示すペイロード情報、（ｉｉ）発生場所情報、（ｉｉｉ）そのデータオブジェクトを生成したノードのローカル時刻に従い付されたタイムスタンプである発生時刻情報、といった注釈も、１個又は複数個含める（付する）ことができる。発生場所情報はそのデータオブジェクトが発生した点を表す情報であり、例えば地理的な位置、ノードＩＤ又はその組合せである。データオブジェクトには、更に、グローバルな規模でユニークな識別子及びシリアルナンバーを含めることができる。それによってそのデータオブジェクトを他の全てのデータオブジェクトと区別することができる。これは、注釈中の発生時刻情報の分解能が十分高くなく当該情報ではデータオブジェクト同士を区別不可能又は困難な場合に、有用である。ランタイムシステムは発生場所情報及び発生時刻情報を追加することができ、アプリケーションはその情報を利用できるかどうかを問い合わせてもし利用できれば利用するよう作成することができる。この種の情報は、ネットワークをグローバルな基準に同期させておらず、またネットワークがローカライズされているわけでもない場合には、助力にならないかもしれない。しかしながら、こうした情報を利用できれば、例えば、同一場所にて発生したが所与の宛先ノードに送信順序通りに届くかどうか分からない複数個のパケットに対し、アプリケーションが時間的順序を付けるのに有用である。データオブジェクトのインスタンスにこれらのタグを付すること及びそれを実行する役割をランタイムシステムに担わせることによって、プログラマがクロック同期、ローカライズ等の仔細に関わる必要がなくなる。
【００４２】
更なる利点としては、そのアプリケーション用のタスクのコードにてタイムスタンプ又は位置座標を必要としていない場合に、プログラマが随意それらに係るフィーチャをオンオフできる、という点がある。このフィーチャをオフすることは高負荷モジュールをコード合成時に除外できるということであり、それによって最終的な計算又は通信オーバヘッドが増加することを避けることができる。データオブジェクトに関連付け得る他の注釈としては、空間寿命又は時間寿命を表す寿命情報がある。即ち、プログラマは、対応するパラメータ値を与えることによって、そのデータオブジェクトが有効性を保つ距離や時間の長さを、そのデータオブジェクトの発生場所又は発生時刻を基準として指定することができる。ランタイムシステムには、寿命が終了したときシステム内にまだそのデータオブジェクトのインスタンスが何れかでも残っていたらガーベージコレクションを実行する、という役割を負わせることができる。また、寿命情報による注釈は例えばデータ頒布範囲制限に使用できる。例えば、タスクからの出力データオブジェクトに「全ノードに頒布」と指定されており且つ空間寿命も指定されているならば、そのデータオブジェクトは、その生成元ノードから送り出された後、その生成元ノードから見て指定空間寿命範囲内にあるノードに対してのみ頒布されることとなる。
【００４３】
各チャネル４２０には、例えば（ｉ）そのチャネルによってあるタスク４２０にリンクされるデータオブジェクト４３０がそのタスクへの入力であるのかそれともそのタスクからの出力であるかを示す入出力連携性情報、（ｉｉ）そのチャネルがプッシュチャネル及びプルチャネルの何れであるかを示すプッシュプル動作情報、といった注釈を、１個又は複数個含める（付する）ことができる。プッシュプル動作情報は、そのチャネルが入力型連携及び出力型連携の何れと注釈されているかによらず注釈できるものであり、このプッシュプル動作情報によって、そのタスク４１０が自発的にデータを動かすのかそれとも何かに反応して動かすのかを、指定することができる。例えば、あるチャネル４２０に対し「入力」且つ「プッシュ」であると注釈されているなら、それは、基本システムにてプロデューサ役のタスクが必要とされること、より詳細にはリモートノード上で動作し生成したデータオブジェクトを生成後直ちに使用場所に向けてプッシュするタスクが必要とされることを、意味している。このようにして、入力及び出力の別とプッシュ及びプルの別とによる何れの組合せにも意味を持たせることができる。なお、プルとは、あるデータオブジェクトを使用するコンシューマ側のタスクにてそのデータオブジェクトが必要になったらそのコンシューマが自ら動作してプロデューサからそのデータオブジェクトを取り込む、ということであり、これに対してプッシュとは、そのデータオブジェクトをコンシューマに送るかどうかをプロデューサが自発的に決定する、ということである。
【００４４】
チャネル４２０に対する注釈としては、他に、そのタスクの注目空間に関する情報、例えば、ノード毎にユーザが指定する隣接範囲ホップ数情報ｋ、ノード毎にユーザがその値を指定する隣接範囲半径情報ｒ等がある。更に、ユーザが指定した領域境界に基づく領域ベース注釈もあり得るし、またユーザが指定したデータオブジェクトオペレータによる属性ベース注釈もあり得る。例えば、ある入力チャネル４２０にｋホップとラベリングされているなら、そのｋホップ隣接範囲内で生成されたデータオブジェクト全てがそのタスクに届くようにそのタスクへの入力経路が形成される。更に、これらチャネル関連の４種類の注釈を組み合わせることもできる。例えば、隣接範囲ホップ数情報ｋによる注釈と属性ベース情報による注釈とを組み合わせてフィルタリングを行うことにより、そのｋホップ隣接範囲内からのデータアイテムのうち所定条件を満足するもののみを、そのチャネルにより届けるデータアイテムとして、指定することができる。
【００４５】
チャネル４２０に対する注釈としては、更に、そのチャネルを通るデータの寿命を示す寿命情報があり得る。この注釈は、ホップ数、伝送距離、生成後経過時間等により規定される満了条件をチャネル４２０に対応付ける注釈である。例えば、あるチャネル４２０を通りあるタスクに届くデータのうちそのその“年齢”が単位時間の所定数倍未満のものだけがそのタスクにとり意味のある（注目すべき）データであるなら、あるチャネル４２０に対して値を指定し時間的満了条件を指定することができる。これと同様の役割はデータオブジェクトに注釈される寿命情報でも果たせる。プログラマの好みやアプリケーションの性質次第で、それらの寿命情報のうち何れを用いてもよい。無論、どのように注釈するかは一般に設計的選択事項である。
【００４６】
チャネル４２０に対する注釈としては、更に端点性質情報があり得る。この注釈によって、各チャネルには「記憶／格納」「最終使用」等とラベリングされる。端点性質情報が「最終使用」であり、且つそのチャネルを介してデータをプッシュできる先のノードのうち何れかにそのデータを使用するタスクがマッピングされていない場合、プッシュする側のノードにおいては、そのコンパイラからランタイムシステムに対し、当該タスク非マップドノードにデータを送らないよう、命令することができる。これに対して、端点性質情報が「記憶／格納」である場合、全宛先ノード上のランタイムシステムがそのデータのコピーをキャッシュする役目を負う。そのため、その端点を収容するチャネルが他のタスクによって注目チャネルとして指定されたときには、そのデータを送ったタスク即ちセンダがそのチャネルの端点を収容していなくても、当該他のタスク即ちリクエスタに対してそのデータが送信される。これは、限定的ではあるがデータオブジェクトを持続的に蓄えておく方法の一つである。また、各ランタイムシステムには、個別にデータ処理及び要求用プロトコル及び処理を実装しておくことができる。このようにすることによって、システム全体として、動的な性質を有するチャネルを注目チャネルとして使用するランタイムシステム群、即ち注目チャネルが新規追加されるシステムや注目チャネルの属性のうち幾つかが動的に変化する（例えばセンシング処理中に隣接範囲属性指定が１ホップから２ホップへと変化する）システムを、サポートすることができる。
【００４７】
図５に本発明の各実施形態にて使用され得るランタイムシステムの例５００を示す。この図に描かれているのはランタイムシステム５００の主要コンポーネントである。そのアプリケーションやプラットフォーム（言語、オペレーティングシステム、ノードのハードウェア等）にもよるが、更なるコンポーネントを設けることもできる。例えば、ネットワークインタフェース及びローカルクロックに時刻同期サービスとのやりとりを行わせれば、そのローカルクロックを隣接ノードと同期させることもできよう。また、コンポーネント間のやりとりを示す矢印付きの線は意図的に図示を省略してある。それは、コンポーネント間の厳密なやりとり関係が様々な原因によって変化し得るためである。
【００４８】
図５において、アプリケーションレベルタスク群５２０は、一組のセンサ、一組のアクチュエータ、センシングインタフェースマネージャ、アクチュエーションインタフェースマネージャ、一組のアプリケーションレベルタスクを含む。また、システムレベルタスク群５４０は、データプールマネージャ５１０、リソースモニタマネージャ５３０、ネットワークインタフェースマネージャ５５０、タスクマネージャ５６０、コンフィギュレーションマネージャ、ローカルクロック（日付／時刻）サービス、ローカライゼーションサービスを含む。ある種の理想的乃至仮想的な構成としては、アプリケーションレベルタスク群５２０がセンシングインタフェース、アクチュエーションインタフェース及びデータプールマネージャ５１０と直接にやりとりでき、他のコンポーネント例えばリソースマネージャ５３０、ネットワークインタフェースマネージャ５５０、タスクマネージャ５６０等が後景に隠れている構成があるが、例えばアプリケーションレベルタスク群５２０がネットワークインタフェースやリソースモニタ／マネージャ５３０に直接にアクセスできる構成もあり得る。そのため、特定のパターンでやりとりが行われるかのような図示は行わないこととし、それによって、システム５００の動作についての誤解や限定解釈が生まれることを避けている。
【００４９】
タスク及び通信チャネルの分配をＡＴａＧに基づき動的に制御し、一組のタスクのパフォーマンスを制御し、またデータオブジェクト及びチャネルを用いてネットワークを設定するには、それを行えるコントローラを用いればよい。
【００５０】
図６に、本発明の実施形態に係るネットワーク合成方法の流れの例を示す。本方法はステップＳ１００にて始まった後、ネットワークをマッピングするステップＳ１２０へと進む。ステップＳ１２０においては、まず一組のタスクを実行させる予定のネットワークを認識させた上で、マッピングが行われる。実施形態にもよるが、ネットワークのマッピングは、そのネットワークを構成するノードの性質、場所等を判別する処理を含んでいる。次いで、本方法による処理はステップＳ１４０へと進む。
【００５１】
ステップＳ１４０においてはＡＴａＧが生成される。生成されるＡＴａＧは一組のタスク、一組のデータオブジェクト及び一組のチャネルを含んでいる。次いで、本方法による処理はステップＳ１６０へと進む。ステップＳ１６０においては、データオブジェクト及びチャネルの性質に基づき、ネットワーク内の対応するノード上でタスクが実行される。そして、本方法による処理はステップＳ１８０へと進んで終了する。
【００５２】
以上、実施形態との関連において様々な細部について説明したが、この説明は実施形態を描像するためのものであり、何か限定を加える趣旨のものではない。また、上述した構成に対し、本願における開示を参照しつつ様々な変形、置換等を施すことができる。例えば、タスクやチャネルに関しまた別の注釈を定めることによって、エンドユーザに対しパフォーマンス上の必須条件及び制限事項を提示することや、事前に定めておいたタスク実行コストを提示することができる。また、同様のＡＴａＧを用いて、そのコストオブパフォーマンスが異なりその実行環境についての前提条件が異なる形態で実施することもできる。チャネルに対し注釈し、選択すべき適切なネットワークレベルプロトコルがどれかを実行時にガイダンスすることもできる。例えば、タスクＴが入力チャネルＣを介しデータオブジェクトＤにリンクしているとする。このチャネルに対して適切に注釈してあれば、プログラマに対し、データオブジェクトＤのインスタンス全てを、それを使用するタスクＴの適切なインスタンスへと直ちにルーティングすべきであることを、示すことができる。
【図面の簡単な説明】
【００５３】
【図１】ネットワーク例を示す図である。
【図２】アブストラクトタスクグラフ例を示す図である。
【図３】注釈付きネットワークグラフ例を示す図である。
【図４】ネットワーク設計用グラフィカルユーザインタフェース例を示す図である。
【図５】ランタイムシステム例を示す図である。
【図６】ネットワーク設定方法例を示すフローチャートである。
【符号の説明】
【００５４】
３３０  ネットワーク、３７０  ノード、２００  ＡＴａＧ（アブストラクトタスクグラフ）、２１０，２２０，２３０，２４０，４１０  タスク，タスクアイテム又はタスクオブジェクト、２１５，２２５，２３５，４３０  データ，データアイテム又はデータオブジェクト、２４５，２５０，２５５，２６０，２６５，２７０，４２０  チャネル。
【図１】
2006146917.tif 000003
【図２】
2006146917.tif 000004
【図３】
2006146917.tif 000005
【図４】
2006146917.tif 000006
【図５】
2006146917.tif 000007
【図６】
2006146917.tif 000008