(57)【要約】本発明の目的は、ネットワークで接続された複数のノードを有する分散システムにおいて、実行モジュールを実行するノードを動的に決定することでシステム全体として効率的な処理が可能な分散システムを提供することである。本発明は、ネットワークで接続された複数のノードを有する分散システムにおいて、前記ノードで実行される実行モジュールに実行条件に関するプロパティが付与され、前記プロパティと、前記分散システムの内部状態に応じて前記実行モジュールを実行するノードが決定されることを特徴とする。
2016207989.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークで接続された複数のノードを有する分散システムにおいて、
前記ノードで実行される実行モジュールに実行条件に関するプロパティが付与され、
前記プロパティと、前記分散システムの内部状態に応じて前記実行モジュールを実行するノードが決定されることを特徴とする分散システム。
【請求項２】
請求項１の分散システムにおいて、
前記内部状態は、前記ノードの処理状態であることを特徴とする分散システム。
【請求項３】
請求項１の分散システムにおいて、
前記内部状態は、前記各ノード間の通信状態であることを特徴とする分散システム。
【請求項４】
請求項１の分散システムにおいて、
前記内部状態の時間的変化に応じて、前記実行モジュールが実行されるノードが決定されることを特徴とする分散システム。
【請求項５】
請求項１の分散システムにおいて、
前記分散システムは、複数の階層を有し、
前記分散システムを構成する階層の時間的変化に応じて、前記実行モジュールが実行されるノードが決定されることを特徴とする分散システム。
【請求項６】
請求項１の分散システムにおいて、
前記プロパティは、前記ノードの処理能力、記憶能力、処理の遅延状態、通信帯域の少なくとも一つであることを特徴とする分散システム。
【請求項７】
請求項１の分散システムにおいて、
前記各ノードによる前記実行モジュールの処理経過、及び、データの蓄積状態の少なくとも一方に応じて、前記実行モジュールが実行されるノードを決定することを特徴とする分散システム。
【請求項８】
請求項１の分散システムにおいて、
前記プロパティが変更可能に構成され、
前記プロパティが変更されることにより、実行モジュールを実行するノードが変更されることを特徴とする分散システム。
【請求項９】
請求項１の分散システムにおいて、
前記実行モジュールの実行主体に決定されたノードが、前記実行モジュールと互換性のある実行モジュールを備える場合に、前記プロパティを基にどちらの実行モジュールを実行するかが決定されることを特徴とする分散システム。
【請求項１０】
請求項１の分散システムにおいて、
前記実行モジュールの移動とともに、該モジュールの入れ替えを行うことを特徴とする分散システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、複数のセンサと複数の計算機及び複数の計算機環境とをネットワークを介して接続し、データ及びプログラムの通信を行い、プログラムを実行する分散システムに関する。
【背景技術】
【０００２】
複数のプログラムを、ネットワークで接続された複数の計算機で別々に実行し、各プログラムを連携させることで一つのアプリケーションのように動作する特許文献１のような分散アプリケーションがある。特許文献１の分散アプリケーションでは、ローカルな通信の優劣度を基にプログラムを静的に配置することで、該分散アプリケーションが複数動作する場合に、分散アプリケーションの優先度が適正に行われることを目的に、該プログラムの配置場所の選択支援を行う発明である。特許文献１の段落００２２の例で示しているように、工場生産設備のように閉じた静的な計算機環境に対応した発明である。【０００３】
また、一つのアプリケーションを一つのマスター計算機で実行し、内部プログラムをネットワークで接続された複数のスレーブ計算機に割り当てて動作するような特許文献２の分散アプリケーションがある。特許文献２の分散アプリケーションでは、マスター計算機において分散アプリケーションを実行するときに、内部プログラムを負荷の少ないスレーブ計算機に担当させることで負荷分散を図り、マスター計算機で最終的な計算結果を得るための発明である。サーバ・クライアント型の計算機システムでの、負荷分散の一実装方式である。【０００４】
なお、Ｍ２Ｍ（Ｍａｃｈｉｎｅ ｔｏ Ｍａｃｈｉｎｅ）、ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）と呼ばれるセンサ及び計算機をインターネット経由で相互接続を実施する環境では、ＭＱＴＴ（http://mqtt.org/）を一例とするプロトコルが使用されており、センサとクラウドとを接続する形態が一般的となっている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００９−２８２６５２号公報
【特許文献２】特開平０６−３４８６６６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
特許文献１の発明では、段落００１４に示されているように、ネットワークのトポロジ-およびネットワークを構成する各回線の属性が示されたネットワーク仕様情報、という事前に決定された静的で且つ固定の情報を基に配置場所を提示するものである。よって、ネットワーク機器や計算機の変更、分散アプリケーションに変更および新たな分散アプリケーションが追加になった場合には、配置をやり直す必要が生じる。また、ネットワーク仕様情報の一つである通信帯域は設計上の理想値と実運用での帯域は定常度および帯域幅が異なるため、ネットワークの経路変更や負荷変動によって、特許文献１が目的とする優先度の維持が困難になる問題点がある。【０００７】
特許文献２の発明では、中央集権構成となるマスター、スレーブのサーバ・クライアント型計算システムであり、図１に示すように、同一の通信媒体に複数の計算機が直接接続できる小規模の閉じた計算機環境を前提としている。そのために、上述のようなセンサとクラウドをインターネットで相互接続する非特許文献１のようなプロトコルで構成されるＭ２Ｍ、ＩｏＴのような大規模な開かれた環境では、多数のクライアント計算機や膨大な量のセンサ・コントローラをマスター計算機で管理する構成を構築することは困難であるという問題がある。つまり、Ｍ２Ｍ、ＩｏＴの相互接続環境では、サーバ・クライアント型ではなくＰ２Ｐ（Ｐｅｅｒ  ｔｏ  Ｐｅｅr）構成が必要となる。【０００８】
本発明の目的は、ネットワークで接続された複数のノードを有する分散システムにおいて、実行モジュールを実行するノードを動的に決定することでシステム全体として効率的な処理が可能な分散システムを提供することである。
【課題を解決するための手段】
【０００９】
本発明は、ネットワークで接続された複数のノードを有する分散システムにおいて、前記ノードで実行される実行モジュールに実行条件に関するプロパティが付与され、前記プロパティと、前記分散システムの内部状態に応じて前記実行モジュールを実行するノードが決定されることを特徴とする。
【発明の効果】
【００１０】
本発明によれば、ネットワークで接続された複数のノードを有する分散システムにおいて、実行モジュールを実行するノードを動的に決定することでシステム全体として効率的な処理が可能なとなる。
【図面の簡単な説明】
【００１１】
【図１】本発明の分散システムの概略図
【図２】本発明におけるプログラム・モジュール及びプロパティの構成図
【図３】本発明における複数ノードで構成される分散システムの例
【図４】計算機リソースは十分であるが、ネットワーク通信帯域が不十分な環境における、プログラム・モジュールの移動の例
【図５】図４におけるプログラム・モジュール移動のフローチャート
【図６】計算機リソース及びネットワーク通信帯域が不十分な環境における、プログラム・モジュールの移動の例
【図７】図６におけるプログラム・モジュール移動のフローチャート
【図８】本発明におけるデータ生成の有無によって、プログラム・モジュールの移動の例
【図９】本発明における自動制御モジュールが車上、地上を行き来する図
【発明を実施するための形態】
【００１２】
以下、本発明の実施形態に係る分散システムの実施例を示す。
【実施例１】
【００１３】
本実施例に係る分散システムは、ネットワークに接続される構成単位（ノード）である複数のセンサ及び複数の計算機がネットワークに接続された計算機環境において、プログラムを構成する複数のプログラム・モジュールをノードに動的に分散させる方法であって、プログラム・モジュールに該モジュールの実行条件となるプロパティを付与し、ネットワークの状態及び計算機の状態を計測する手段と、該計測手段の結果とプロパティによりプログラム・モジュールを実行するノードを決定する判断手段と、該プログラム・モジュールがノード間で移動する手段と、を有する動的分散方法に関するものである。なお、プログラム・モジュールの処理経過、データの蓄積状況、配置状況を記憶し、該記憶状況に応じて、該プログラム・モジュールを配置してもよい。また、該記憶状況に応じて律速段階を抽出して、最適なプロパティを提示してもよい。【００１４】
＜概略構成＞
実施例１における分散システムの概略図を図１に示す。センサ等のデバイス１１、コントローラ１２、ゲートウェイ１３、ルータ１４、サーバをはじめとする複数の計算機を有するクラウド等の最終ドメイン１５、これらネットワークに接続される構成物を総称してノード３０と呼ぶ。この分散システムでは、下位のノードであるデバイス１１から上位のノードである最終ドメイン１５に至るまで、各ノードが階層的に配置されている。なお、複数のノードを接続するために複数設置されるスイッチのようなノードは図１では省略している。【００１５】
センサデバイス１１とコントローラ１２を繋ぐ通信路２１、コントローラ１２とゲートウェイ１３を接続する通信路２２、ローカルエリアネットワークＬＡＮ２３と、外部ネットワークとの接続を担うルータ１４、インターネットを代表とするワイドエリアネットワークＷＡＮ２４、とがある。これらを総称してネットワーク２０と呼ぶ。センサデバイス１１とコントローラ１２を繋ぐ通信路２１には、電圧等の物理的データをやりとりするためにワイヤリング、物理データをデジタルデータとしてやりとりするためのＳＰＩ、Ｉ２Ｃ、さらに高速な有線ネットワーク、もしくは低速低消費電力の無線通信もしくは高速大消費電力の無線通信を利用するが一般的である。コントローラ１２とゲートウェイ１３を接続する通信路２２には、通信路２１と同様に高速有線ネットワーク、Ｗｉ−Ｆｉが一般的である。ゲートウェイ１３とルータ１４を結ぶＬＡＮ２３、ルータ１４と最終ドメイン１５を結ぶＷＡＮ１４にも高速有線ネットワークが一般的である。【００１６】
本実施例における分散システムに接続されているノードの種類及び構成は一実施例であってこの限りではない。例えば最終ドメイン内も、ルータやファイアウォールを始めとするゲートウェアによって構成されている場合が多い。また、通信路の通信メディアとしては大きく分けて有線、無線があるがどちらを採用しても構わない。なお、無線には常時接続可能が携帯電話の地上通信網や、時間帯によっては接続が不可能となる衛星通信網があるが、本実施例ではこのような通信メディアの差異を隠蔽するのにも有効である。【００１７】
＜ノードとプロパティ＞
図２では、本実施例におけるノード３０の内部構造の一例を示す。なお、ノード３０は、図１に示した各ノード１１、１２、１３、１４、１５のいずれかもが該当し得るものであるため、具体的なノードを特定し得る符号１１〜１５とは異なる符号３０を用いている。【００１８】
本実施例の分散システムでは、ノード３０で実行される実行モジュールに実行条件に関するプロパティが付与され、この実行モジュールを実行するノードは、プロパティ８０と、分散システムの内部状態に応じて決定される。ここで、分散システムの内部状態としては、分散システムを構成するノード３０の処理状態や、各ノード３０間の通信状態が挙げられる。また、ノード３０の処理状態とは、具体的には、ノード３０の処理能力（又は処理負荷）や記憶能力（即ち、記憶容量）であり、通信状態とは、通信能力や通信帯域の大きさである。このような内部状態は、時間的に変化し得るものであり、従って、この分散システムでは、実行モジュールを実行するノードが時間的に変化し得る。また、上述のように、分散システムは複数の階層を有するものであるが、分散システムを構成する階層が時間的に変化する場合もある。階層の時間的変化とは、図１を用いて一例を説明すると、「当初下層から上層にかけて順にデバイス１１、コントローラ１２、ゲートウェイ１３、ルータ１４、最終ドメイン１５で構成されていた状態から、ゲートウェイ１３やルータ１４といった中間のノードを経由しないでコントローラ１２と最終ドメイン１５とが直接通信する」といったように、階層構造が変化することである。【００１９】
実行環境４０は、モジュール５０が動作する環境である。モジュール５０は一つ以上のデバイス１１を基にデータ６０を処理・生成をする処理単位である。なお、モジュール５０は、処理を実行するモジュールであることから、実行モジュールと称することができる。移動手段７１はモジュール５０及びデータ６０を他のノード３０に移動する手段である。計測手段７２はノード３０に係る状態を計測する手段である。判断手段７３は、計測手段７２で得られた状態とプロパティ８０に記録されたデータを基に、モジュール５０を移動すべきか否かを判断する手段である。具体的には、プロパティ８０には、モジュール５０の実行に必要な処理性能８１、モジュール５０の実行時間に許容される遅延時間８２、モジュール５０の実行に係るデータ６０の通信に必要な通信帯域８３、同様にモジュール５０の実行に係るデータ６０の記憶に必要な記憶領域の容量８４等が記録されている。【００２０】
実行環境４０の一般的な環境には、オペレーティング・システム（ＯＳ）がある。ただしＯＳには、ハードウェア依存性やＯＳ固有要素があるために、ＯＳ間で互換性が無い場合がある。分散システムを構築する際にＯＳを一意に決定しまうとシステム構成に柔軟性がなくなる。そこで、ＯＳ依存性を解消するために、ＯＳ上で動作するインタープリタや仮想マシン（ＶＭ）がある。ノード３０の間でのモジュール５０の移動は、前述のＯＳであれば、実行形式のファイル、静的・動的ライブラリを転送することで実現できる。インタープリタの場合には、モジュール５０のデータ形式が定められており、該データを転送することで実現できる。例えば、インタープリタで普及しているプログラミング言語環境の一種では中間形式が定められている。ＶＭの場合にも同様に、モジュールのシリアライズデータ形式が定められており、該データを転送することで実現できる。例えば普及しているＶＭ型インタープリタでは、シリアライズという手段によって、ノード間でのデータ転送を可能としている。ＶＭ実行環境では、ＶＭ実行環境一式をファイルとして管理しており、該実行環境をそのまま別のノードで実行させることを可能としている。本実施例では、プロパティ８０に処理性能８１、遅延時間８２、通信帯域８３、記憶容量８４を例として提示したが、該プロパティは、モジュール５０に係る要求や運用状況に応じて決定するものであり、この限りではない。【００２１】
なお、判断手段７３の実行開始タイミングは、スケジューラによる定期的実行、若しくは実行環境４０で管理するイベントによって実行しても良い。例えば一般的なＯＳに搭載されている割込み処理でも構わない。【００２２】
＜ノード分散＞
図３は、複数ノードで構成される分散システムの構成例を示す。この構成例では、センサのデータを取得して、該データに前処理を施して中間データを生成し、該中間データを後処理して結果となるデータを得る一連の処理が行われる。センサノード３１では、計測モジュール５１がセンサデバイス１１のデータを計測し、センサデータ６１を生成する。【００２３】
前処理ノード３２では、センサノード３１からのセンサデータ６１を基に、前処理モジュール５２がセンサデータ６１を前処理して中間データ６２を生成する。後処理ノード３３では、前処理モジュール３２からの中間データ６２を基に、後処理モジュール５３が中間データ６２を後処理して結果データ６３を生成する構成例である。この構成例では、センサノード３１が図１のデバイス１１に対応し、後処理モジュール３３が図１の最終ドメイン１５内のいずれかのノード３０に対応し、前処理モジュールがプロパティ８０に応じて何れかのノード３０にて処理される構成となる。本実施例では、処理ノードを前処理ノードと後処理ノードの２ノードとしているがこの限りではない。モジュール５０の個数や処理内容は、システム全体に対する要求や運用状況によって左右されるものである。【００２４】
＜センサークラウド（クラウドにプログラム）＞
図４では、実施例３で示した複数ノードに分散されるシステム構成に至るまでの概略を示す。この例では、計算機リソースは十分である最終ドメイン１５と、ネットワーク２１、２２、２３、２４の通信帯域が不十分である環境でセンサノード９１と接続する場合の、プログラム・モジュールの移動状況の一例である。【００２５】
図４（ａ）は、ＩｏＴにおける、末端のセンサのデータを終端のクラウドシステムに集約して大規模な処理を施すシステム構成に相当する。この構成は、大多数のセンサとクラウドシステムを接続するだけの構成であり、構築が容易である。【００２６】
センサノード９１は、一つ以上のセンサデバイス１１を有し、計測モジュール５１は実行環境４０上で動作してセンサデバイス１１から多量のセンサデータ６１を取得する。アプリケーションノード９２は、該センサデータ６１を処理して集約された中間データ６２を生成する前処理モジュール５２、該中間データ６２を処理して結果データ６３を生成する後処理モジュールを有する。なお、センサノード９１、アプリケーションノード９２はともに、移動手段６１、計測手段７２、判断手段７３を有する。【００２７】
この構成において、該センサ群とクラウドシステムを繋ぐネットワークの通信帯域が十分でない場合センサのデータの取得が困難となる。その場合、判断手段７３が各モジュール５２，５３に付随するプロパティ８０に応じて、前処理モジュール５２が、例えばセンサデータ６１よりも容量の少ない中間データ６２で通信負荷が軽減されると判断し、図４（ｂ）に示すように、別のノード９３で実行できるように移動手段７１により、前処理モジュール５２を該ノード９３に転送し、該ノード９３の実行環境４０にて処理を実行する。【００２８】
上記で説明したように、計算機リソースが十分にあるクラウドやサーバと、複数のセンサを接続する、Ｍ２ＭやＩｏＴの分散システムを、通信帯域が不十分なネットワークを経由して構成する場合に、従来であれば通信がボトルネックとなって十分な処理性能が得られない場合でも、上述した処理を行えば、クラウドやサーバと複数のセンサを結ぶネットワーク上のノードを有効活用できるとともに、ノード間を結ぶネットワーク帯域及びノードの性能に応じて、動的に適切なノードにモジュールが配置されることによってシステム全体として十分な処理性能が得られる。【００２９】
図５は、図４で示したプログラム・モジュール５０の移動に係るフローチャートを示す。アプリケーションノード９２の計測手段７２は、ネットワーク２１、２２、２３、２４を経由して通信相手先を探索して該ネットワーク上で経由するノード３０の一覧を取得する（Ｓ１０）。【００３０】
アプリケーションノード９２の計測手段７２はプロパティ８０に記録された項目に応じて自ノード３０の状況を計測する（Ｓ２０）。さらに計測手段７２はノード一覧の他ノード状況を取得する（Ｓ３０）。アプリケーションノード９２の判断手段７３は各モジュール５２，５３に付与されたプロパティ８０を基に、自ノード及び他ノードで適当なノード３０を選択する（Ｓ４０）。【００３１】
例えば、前処理モジュール５２が選択ノード９３で中間データ６２を生成するのが良いと判断したとする。選択ノードが自ノードの場合には、処理を継続する（Ｓ４２）。選択ノードが他ノードの場合には、選択したノード９３に前処理モジュール５２の中間データ６２の通信相手を自ノードと設定して転送する（Ｓ５０）。【００３２】
選択ノード９３は、該モジュール５２を受信する（Ｓ５２）。転送先ノード３０に、転送した前処理モジュール５２の起動を依頼する（Ｓ６０）。選択ノード９３は、起動の依頼を受領して前処理モジュール５２を起動する（Ｓ６２）アプリケーションノード９２は、現在通信しているセンサノード９１に、転送先ノード９３への変更を通知する（Ｓ７０）。【００３３】
センサノード９１は通信先をアプリケーションノード９２から転送先ノード９３に変更する（Ｓ７２）。以上により、センサノード９１、転送ノード９３、アプリケーションノード９２の接続同期が完了する（Ｓ８０）。このように、プロパティ８０に応じて、モジュール３０を実行するのに適切なノード３０を動的に選択することにより、Ｍ２Ｍ、ＩｏＴのような大規模で且つ運用状態が流動的な分散システムにおいてもシステムが効率的に運用することが可能となる。【００３４】
＜センサークラウド（センサにプログラム）＞
図４及び図５の例では、クラウドにプログラムが存在する例を示したが、次の図６、７では、センサにプログラムが存在する例を示す。【００３５】
図６では、計算機リソース及びネットワークの通信帯域が不十分である環境における、プログラム・モジュールの移動状況の一例を示す。この例では、莫大な個数のセンサノード９４を、ネットワーク２１、２２、２３、２４を経由して、最終ドメイン１５に設置された監視ノード９５を接続する場合の、プログラム・モジュールの移動状況の一例である。図６（ａ）は、ＩｏＴにおける、遠隔地に多数設置したセンサの情報をリモート監視する大規模監視センターを構成する監視ノード９５に相当する。この構成は、大多数のセンサとクラウドシステムを接続するだけの構成であり、構築が容易である。【００３６】
センサノード９４は、少なくとも一つ以上のセンサデバイス１１を有し、該ノードで結果データ６３を生成できるように、計測モジュール５１、前処理モジュール５２、後処理モジュール５３を有し、実行環境４０で動作させることで、計測モジュール５１は、センサデバイス１１から多量のセンサデータ６１を取得する。前処理モジュール５２は、該センサデータ６１を処理して中間データ６２を生成する。後処理モジュール５３は、結果データ６３を生成する。結果データ６３はネットワーク２１、２２、２３、２４を経由して監視ノード９５に転送される。なお、センサノード９１、アプリケーションノード９２はともに、移動手段６１、計測手段７２、判断手段７３を有する。【００３７】
この構成において、センサの低価格化を狙ってノード３０の演算処理能力及び通信能力を最低限まで絞ったものであった場合、高度な処理を実行できずに遅延が発生するおそれがある。その場合、判断手段７３が各モジュール５２、５３に付随するプロパティ８０に応じて、例えば、計測モジュール５１の実行にしかセンサノードが適さないと判断すると、図６（ｂ）に示すように、前処理モジュール５２と後処理モジュール５３を他のノードに転送し、実行環境４０にて実行する。本実施例では、転送ノード９３でもプロパティ８０に適さない場合に、更に後処理モジュール５３を監視モジュール９５に転送して実行する構成となっている。【００３８】
上記で説明したように、計算機リソースが不十分なセンサノードを計測対象に設置し、且つ通信帯域が不十分なネットワークを経由して処理結果を受信するノードに接続する場合において、従来であればセンサノードの貧弱な処理性能及び不十分な通信がボトルネックとなって、分散システムとして成立しない場合であっても、上述した処理を行えば、センサノードをネットワークに接続するだけで、ノード間を結ぶネットワーク帯域及びノードの性能に応じて、動的に適切なノードにモジュールが配置されることによってシステム全体として十分な処理性能が得られる。【００３９】
図７では、実施例６でのプログラム・モジュール５０の移動に係るフローチャートを示す。センサノード９４の計測手段７２は、ネットワーク２１、２２、２３、２４を経由して通信相手先を探索して該ネットワーク上で経由するノード３０の一覧を取得する（Ｓ１１０）。センサノード９４の計測手段７２はプロパティ８０に記録された項目に応じて自ノード３０の状況を計測する（Ｓ１２０）。【００４０】
さらに計測手段７２はノード一覧の他ノード状況を取得する（Ｓ１３０）。センサノード９２の判断手段７３は各モジュール５２，５３に付与されたプロパティ８０を基に、自ノード及び他ノードで適当なノード３０を選択する（Ｓ１４０）。【００４１】
例えば、前処理モジュール５２と後処理モジュール５３が選択ノード９６で中間データ６２を生成するのが良いと判断したとする。選択ノードが自ノードの場合には、処理を継続する（Ｓ１４２）。選択ノードが他ノードの場合には、選択したノード９３に前処理モジュール５２の通信相手を自ノードと設定して転送する（Ｓ１５０）。選択ノード９３は、該モジュール５２、５３を受信する（Ｓ１５２）。転送先ノード３０に、転送した前処理モジュール５２及び後処理モジュール５３の起動を依頼する（Ｓ１６０）。【００４２】
選択ノード９６は、起動の依頼を受領して前処理モジュール５２及び後処理モジュール５３を起動する（Ｓ１６２）。センサノード９４は、現在通信している監視ノード９５に、転送先ノード９６への変更を通知する（Ｓ１７０）。監視ノード９５は通信先をセンサノード９４から転送先ノード９６に変更する（Ｓ１７２）。【００４３】
以上により、センサノード９４、選択ノード９６、監視ノードノード９５の接続同期が完了する（Ｓ１８０）。ここで、選択ノード９６において、新たに前処理モジュール５２、後処理モジュール５３を実行環境４０で実行することにより変化が生じたものとする。【００４４】
選択ノード９６の計測手段７２は、ネットワーク２１、２２、２３、２４を経由して通信相手先を探索して該ネットワーク上で経由するノード３０の一覧を取得する（Ｓ１９０）。選択ノード９６の計測手段７２はプロパティ８０に記録された項目に応じて自ノード３０の状況を計測する（Ｓ２００）。さらに計測手段７２はノード一覧の他ノード状況を取得する（Ｓ２１０）。選択ノード９６の判断手段７３は各モジュール５２，５３に付与されたプロパティ８０を基に、自ノード及び他ノードで適当なノード３０を選択する（Ｓ２２０）。本実施例では、後処理モジュール５３が監視ノード９５で結果データ６３を生成するのが良いと判断したとする。選択ノードが自ノードの場合には、処理を継続する（Ｓ２２２）。選択ノードが他ノードの場合には、選択したノード９５に後処理モジュール５３の通信相手を自ノードと設定して転送する（Ｓ２３０）。【００４５】
監視ノード９５は、後処理モジュール５３を受信する（Ｓ２３２）。監視ノード９５に、転送した後処理モジュール５３の起動を依頼する（Ｓ２４０）。監視ノード９５は、起動の依頼を受領して後処理モジュール５３を起動する（Ｓ２４２）。選択ノード９６は、現在通信している監視ノード９５に、監視ノード９５への変更を通知する（Ｓ２５０）。監視ノード９５は通信先をセンサノード９４から転送先ノード９６に変更する（Ｓ２５２）。以上により、センサノード９４、選択ノード９６、監視ノード９５の接続同期が完了する（Ｓ１８）。【００４６】
上記で説明したように、モジュール５０を、ネットワーク２１、２２、２３、２４を経由して、判断手段７３に従ってモジュール４０を転送することによって、適切なノード３０に動的にモジュール４０を配置・実行することができる。即ち、本実施例によれば、複数のセンサ及び複数の計算機がネットワークに接続された環境で、ネットワークの通信状況及び計算機の状況に応じて、プログラムを構成する複数プログラム・モジュールが動的に計算機間を移動、実行できる環境を提供することができる。また、動的分散方式を用いることで、ネットワーク経路変更や負荷変動および計算機状況に応じて動的にプログラム・モジュールが実行される。よって、ネットワーク優先度やマスター・スレーブのような計算機の構成を静的に構成する必要がなく、インターネットのようにネットワーク優先度の決定が困難で且つ計算機資源が逐次変化する環境でも有効に活用することが可能となる。
【実施例２】
【００４７】
実施例２は、システムの実行状態が大きく変化する例として、センサのデータを基に計測対象の状況を学習する段階と、該学習結果を基に計測対象を常時診断する段階の大きく二つの段階を有するシステムの例である。【００４８】
図８（ａ）に示す初期段階では、計測対象に設置するコントローラ９６は、センサデバイス１１と接続し、計測モジュール５１により、センサデータ１１１を取得する。特徴抽出モジュール１０１は、該センサデータ１１１から、特徴データ６２を抽出する。学習モジュール１０２は、特徴データ６２を基に、学習データ１１２を生成する。該学習データ１１２とセンサデータ１１を基に、診断モジュール１０３は正常／異常の判断を下し、異常の場合には異常データ１１３を生成して、最終ドメイン１５に設置されているセンター９７に異常データ１１３を通知する。【００４９】
初期段階では、学習データ１１２は存在せず、且つ学習モジュール１０２の処理は大きく、膨大な量のセンサデータ１１１を処理・記憶することは、コントローラ９６で実行することは困難である。実際、コントローラ９６の仕様上、コントローラ９６で実行することが困難となるようにプロパティ８０を設定せざるを得ない。【００５０】
そこで図８（ｂ）に示すように、センター９７との間に設置された中継ノード９８で、特徴抽出モジュール１０１を実行し、センサデータ１１１から特徴データ６２を生成する。中継ノード９８で生成された特徴データ６２を基に、センター９７では、学習モジュール１０２が、学習データ１１２を生成する。【００５１】
図９（ｃ）に示すように、コントローラ９６は、学習データ１１２を基にセンサデータ１１１を診断モジュール１０３で診断処理を実施し、正常／異常の判断を下し、異常の場合には異常データ１１３を生成して、ネットワーク２１、２２、２３、２４を経由してセンター９７に異常データを通知する。【００５２】
上記で説明したように、学習データ１１２の生成状況により適切なノードで処理を実行させることが可能となる。
【実施例３】
【００５３】
実施例３は、プロパティの変更により、システム全体の構成を容易に変更する例を示す。本実施例は、自動車の自動運転や安全制御システムのコントローラ３００に適用した例である。【００５４】
図９（ａ）は、例えば自動車に搭載されるセンサ１６と、アクチュエータ１７と、コントローラ３００を示す。センサ１６は、一次元の距離センサや二次元のカメラ、三次元のステレオカメラやレーザー・レンジ・ファインダ等の様々な次元に対応したセンサによって構成されている。コントローラ３００では、これらのセンサから得られる多次元データ２１１を基に、次元処理モジュール２０１は、特徴データ２１２を生成する。特徴データ２１２には、距離データや物体検知の結果等がある。認識モジュール２０２は、特徴データ２１２を基に、認識データ２１３を生成する。認識データ２１３を基に制御モジュール２０３はアクチュエータ１７を操作するための目標値となる制御データ２１４を生成する。制御の目標にもよるが、アクチュエータ１７には、制動のためのブレーキ・アクチュエータ、操舵のためのステア・アクチュエータ、加減速のためのアクセル・アクチュエータ、等がある。この構成が、現在のオートクルーズコントロールや、安全装備であるＡＤＡＳの概略構成である。この構成では、個々の車体に、センサデバイス１１と処理モジュール５０が搭載されるため、コストがかかりがちであり、また、車車間での連携が取りにくいおそれがある。【００５５】
図９（ｂ）の例では、認識モジュール２０２と制御モジュール２０３に係るプロパティを操作することにより、特徴データ２０１の生成までを車上で実施し、認識データ２１３の生成や、制御データ２１４の生成は、路上システム３１０、３２０で実施する構成にしている。【００５６】
さらに、図９（ｃ）の例では、車上に搭載されるのはセンサ１６とアクチュエータ１７だけとなり、センサ１６からの多次元データ２２１を、ネットワーク２１、２２、２３、２４を経由して、路上システム３２０に送信し、路上システム３２０側で、次元処理モジュール２０１、認識モジュール２０２、制御モジュール２０３を実施する形態にすることが可能となる。【００５７】
上記で説明したように、図９（ａ）のように制御システム３００を全ての自動車に搭載することで、運転者主体の自律的なシステムが構築できる。ただし、制御システム３００は高性能が要求されるために高価になるとともに、莫大な量の制御システム３００を連携して管理することが困難である。一方、図９（ｂ）に示す構成を採用すれば、認識モジュール２０２や制御モジュール２０３を外部のノードで実行させることができるので、制御システム３００の処理能力を削減することでコスト削減が可能となる。また、制御システム３００でハードウェア依存の少ない認識モジュール２０２や制御モジュール２０３を、車の外部（例えば地上）に設置することで、認識モジュール２０２や制御モジュール２０３のスケーラビリティを確保するとともに各モジュールの連携もソフト的に容易となる。この場合、地上システム３１０、３２０は、例えば路車間通信が可能となる道路脇に設置されても良いし、通信遅延が許容できるのであれば遠距離に設置される最終ドメイン１５であっても構わない。地上側の設備において認識モジュール２０２や制御モジュール２０３を実行する構成にすることにより、精度を向上させた認識モジュール２０２の変更や、精度良い制御を実行できる制御モジュール２０３に変更することが可能となる。図９（ｃ）の構成では、車に搭載されるのは、センサ１７とアクチュエータ１６だけとなり、センサ１６で計測された多次元データ２１１を、ネットワーク２１，２２，２３，２４を経由して地上システム３２０で、集中的に認識、制御を管理する自動運転システムへの移行が可能となる。【００５８】
なお、本発明は、上記各実施形態の構成に限定されるものではなく、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。【００５９】
例えば、上記では、実行環境として、ＯＳやＶＭ環境といったソフトウェアによるものを例示したが、ハードウェアによるものであってもよく、ハードウェアの実行環境としては、再構成可能（re-configurable）なデバイスとして、ＰＬＤやＦＰＧＡが考えられる。
【符号の説明】
【００６０】
１１…デバイス、１２…コントローラ、１３…ゲートウェイ、１４…ルータ、１５…最終ドメイン、２１…通信路、２２…通信路、２３…ＬＡＮ、２４…ＷＡＮ、３０…ノード、４０…実行環境、５０…モジュール、６０…データ、７１…移動手段、７２…計測手段、７３…判別手段、８０…プロパティ
【図１】
2016207989.tif 000003
【図２】
2016207989.tif 000004
【図３】
2016207989.tif 000005
【図４】
2016207989.tif 000006
【図５】
2016207989.tif 000007
【図６】
2016207989.tif 000008
【図７】
2016207989.tif 000009
【図８】
2016207989.tif 000010
【図９】
2016207989.tif 000011
【国際調査報告】
2016207989.tif 000012
2016207989.tif 000013
2016207989.tif 000014
2016207989.tif 000015