(57)【特許請求の範囲】
【請求項１】
それぞれが機能を実現する複数の処理を連結するデータ処理システムであって、
データを入力するゲートウェイと、
前記ゲートウェイから出力されるデータを入力するサーバと
を有し、
前記ゲートウェイは、
第１のフロー情報に含まれる情報にしたがって、入力したデータへ１以上の処理を含む第１の処理を適用して前記サーバへ出力し、
前記サーバは、
前記第１のフロー情報に含まれる情報にしたがって、前記ゲートウェイから入力したデータへ第２の処理を適用して、その後に１以上の処理を含む第３の処理を適用し、
前記第２の処理を特定し、
前記サーバが前記ゲートウェイから入力したデータへ前記第３の処理を適用するための情報を含む第２のフロー情報を、前記第１のフロー情報から生成し、
前記ゲートウェイが入力したデータへ前記第１の処理を適用してその後に前記第２の処理を適用するための情報を含む前記第２のフロー情報を、前記第１のフロー情報から生成すること
を特徴とするデータ処理システム。
【請求項２】
請求項１に記載のデータ処理システムであって、
前記ゲートウェイは、
それぞれにセンサＩＤが付与された複数のセンサからデータを入力し、
前記サーバは、
前記第１のフロー情報として、ゲートウェイ内フローＩＤと、前記第１の処理のＩＤとが関連付けられた情報が格納され、サーバ内フローＩＤと、順番付けられた前記第２の処理のＩＤおよび前記第３の処理のＩＤとが関連付けられた情報が格納されたフロー定義テーブルと、
センサＩＤとゲートウェイ内フローＩＤとが関連付けられたゲートウェイ内ルーティングテーブルと、
センサＩＤとサーバ内フローＩＤとが関連付けられたサーバ内ルーティングテーブルと
を有し、
前記フロー定義テーブルを用いて、前記第２の処理のＩＤからサーバ内フローＩＤを特定し、
前記サーバ内ルーティングテーブルを用いて、特定されたサーバ内フローＩＤからセンサＩＤを特定して、サーバ内フローＩＤを更新し、
前記フロー定義テーブルを用いて、更新されたサーバ内フローＩＤと前記第３の処理のＩＤを関連付けることにより、前記サーバが前記ゲートウェイから入力したデータへ前記第３の処理を適用する情報を含む前記第２のフロー情報を生成し、
前記ゲートウェイ内ルーティングテーブルを用いて、特定されたセンサＩＤからゲートウェイ内フローＩＤを特定し、
前記フロー定義テーブルを用いて、新たなゲートウェイ内ＩＤと、順番付けられた前記第１の処理のＩＤおよび前記第２の処理のＩＤとを関連付けることにより、前記ゲートウェイが、入力したデータへ前記第１の処理を適用して、その後に前記第２の処理を適用する情報を含む前記第２のフロー情報を生成すること
を特徴とするデータ処理システム。
【請求項３】
請求項１に記載のデータ処理システムであって、
前記ゲートウェイは、
第１のセンサと第２のセンサのそれぞれからデータを入力し、
前記第１のフロー情報は、
前記第１のセンサから前記ゲートウェイを経由して入力したデータへ前記第２の処理を適用して、その後に１以上の処理を含む前記第３の処理を適用し、前記第２のセンサから前記ゲートウェイを経由して入力したデータへ第４の処理を適用して、その後に１以上の処理を含む第５の処理を適用するための情報を含み、
前記サーバは、
前記第４の処理を特定し、
前記ゲートウェイにおいて、前記第４の処理を適用できるか否かを判定し、前記第４の処理を適用できないと判定すると、前記第２の処理を特定し、
前記ゲートウェイにおいて、前記第２の処理を適用できるか否かを判定し、前記第２の処理を適用できると判定すると、前記第２のフロー情報を生成すること
を特徴とするデータ処理システム。
【請求項４】
請求項３に記載のデータ処理システムであって、
前記サーバは、
前記ゲートウェイにおいて、前記第２の処理および前記第４の処理のそれぞれが適用できるか否かの情報が格納された管理テーブルを有し、
前記管理テーブルを用いて、前記第４の処理が適用できるか否かを判定し、前記第２の処理が適用できるか否かを判定すること
を特徴とするデータ処理システム。
【請求項５】
請求項４に記載のデータ処理システムであって、
前記サーバは、
前記管理テーブルを用いた判定において、前記第４の処理が適用できると判定すると、前記ゲートウェイにおける前記第４の処理の負荷を算出し、算出した負荷が予め設定された閾値未満であるか否かを判定し、閾値未満でないと判定すると、前記第４の処理を適用できないと判定し、
前記管理テーブルを用いた判定において、前記第２の処理が適用できると判定すると、前記ゲートウェイにおける前記第２の処理の負荷を算出し、算出した負荷が予め設定された閾値未満であるか否かを判定し、閾値未満であると判定すると、前記第２の処理を適用できると判定すること
を特徴とするデータ処理システム。
【請求項６】
請求項５に記載のデータ処理システムであって、
前記ゲートウェイは、
前記ゲートウェイにおける負荷の情報を前記サーバへ通知し、
前記サーバは、
前記ゲートウェイから入力したデータに対する、前記サーバにおける前記第４の処理の負荷を算出し、前記ゲートウェイと前記サーバとの性能比に基づいて、前記ゲートウェイにおける前記第４の処理の負荷を算出し、
前記ゲートウェイから入力したデータに対する、前記サーバにおける前記第２の処理の負荷を算出し、前記ゲートウェイと前記サーバとの性能比に基づいて、前記ゲートウェイにおける前記第２の処理の負荷を算出すること
を特徴とするデータ処理システム。
【請求項７】
請求項１に記載のデータ処理システムであって、
前記サーバは、
ゲートウェイ内フローＩＤと、前記第１の処理のＩＤとが関連付けられた情報を含む前記第１のフロー情報が格納され、サーバ内フローＩＤと、順番付けられた前記第２の処理のＩＤおよび前記第３の処理のＩＤとが関連付けられた情報を含む前記第１のフロー情報が格納されたフロー定義テーブルと、
センサＩＤとゲートウェイ内フローＩＤとが関連付けられたゲートウェイ内ルーティングテーブルと、
センサＩＤとサーバ内フローＩＤとが関連付けられたサーバ内ルーティングテーブルと、
前記フロー定義テーブルおよび前記サーバ内ルーティングテーブルに基づいて、第２の処理を適用して、その後に１以上の処理を含む第３の処理を適用するフローへ、前記ゲートウェイから入力したデータを振り分けるサーバ内振分部と
を有し、
前記ゲートウェイは、
それぞれにセンサＩＤが付与された複数のセンサからデータを入力し、
前記フロー定義テーブルおよび前記ゲートウェイ内ルーティングテーブルを前記サーバから取得し、
取得した前記フロー定義テーブルおよび前記ゲートウェイ内ルーティングテーブルに基づいて、第１の処理を適用するフローへ、前記センサから入力したデータを振り分けるゲートウェイ内振分部を有すること
を特徴とするデータ処理システム。
【請求項８】
それぞれが機能を実現する複数の処理を連結するデータ処理システムの制御方法であって、
前記データ処理システムは、
データを入力するゲートウェイと、
前記ゲートウェイから出力されるデータを入力するサーバと
を有し、
第１のフロー情報は、
前記ゲートウェイにおいて入力したデータへ１以上の処理を含む第１の処理を適用し、前記サーバにおいて前記ゲートウェイから入力したデータへ第２の処理を適用して、その後に１以上の処理を含む第３の処理を適用するための情報を含み、
前記サーバは、
前記第２の処理を特定し、
前記サーバが前記ゲートウェイから入力したデータへ前記第３の処理を適用するための情報を含む第２のフロー情報を、前記第１のフロー情報から生成し、
前記ゲートウェイが入力したデータへ前記第１の処理を適用してその後に前記第２の処理を適用するための情報を含む前記第２のフロー情報を、前記第１のフロー情報から生成すること
を特徴とするデータ処理システムの制御方法。
【請求項９】
請求項８に記載のデータ処理システムの制御方法であって、
前記ゲートウェイは、
それぞれにセンサＩＤが付与された複数のセンサからデータを入力し、
前記サーバは、
前記第１のフロー情報として、ゲートウェイ内フローＩＤと、前記第１の処理のＩＤとが関連付けられた情報が格納され、サーバ内フローＩＤと、順番付けられた前記第２の処理のＩＤおよび前記第３の処理のＩＤとが関連付けられた情報が格納されたフロー定義テーブルと、
センサＩＤとゲートウェイ内フローＩＤとが関連付けられたゲートウェイ内ルーティングテーブルと、
センサＩＤとサーバ内フローＩＤとが関連付けられたサーバ内ルーティングテーブルと
を有し、
前記フロー定義テーブルを用いて、前記第２の処理のＩＤからサーバ内フローＩＤを特定し、
前記サーバ内ルーティングテーブルを用いて、特定されたサーバ内フローＩＤからセンサＩＤを特定して、サーバ内フローＩＤを更新し、
前記フロー定義テーブルを用いて、更新されたサーバ内フローＩＤと前記第３の処理のＩＤを関連付けることにより、前記サーバが前記ゲートウェイから入力したデータへ前記第３の処理を適用する情報を含む前記第２のフロー情報を生成し、
前記ゲートウェイ内ルーティングテーブルを用いて、特定されたセンサＩＤからゲートウェイ内フローＩＤを特定し、
前記フロー定義テーブルを用いて、新たなゲートウェイ内ＩＤと、順番付けられた前記第１の処理のＩＤおよび前記第２の処理のＩＤとを関連付けることにより、前記ゲートウェイが、入力したデータへ前記第１の処理を適用して、その後に前記第２の処理を適用する情報を含む前記第２のフロー情報を生成すること
を特徴とするデータ処理システムの制御方法。
【請求項１０】
請求項８に記載のデータ処理システムの制御方法であって、
前記ゲートウェイは、
第１のセンサと第２のセンサのそれぞれからデータを入力し、
前記第１のフロー情報は、
前記第１のセンサから前記ゲートウェイを経由して入力したデータへ前記第２の処理を適用して、その後に１以上の処理を含む前記第３の処理を適用し、前記第２のセンサから前記ゲートウェイを経由して入力したデータへ第４の処理を適用して、その後に１以上の処理を含む第５の処理を適用するための情報を含み、
前記サーバは、
前記第４の処理を特定し、
前記ゲートウェイにおいて、前記第４の処理を適用できるか否かを判定し、前記第４の処理を適用できないと判定すると、前記第２の処理を特定し、
前記ゲートウェイにおいて、前記第２の処理を適用できるか否かを判定し、前記第２の処理を適用できると判定すると、前記第２のフロー情報を生成すること
を特徴とするデータ処理システムの制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ処理システムおよびその制御方法に関する。
【背景技術】
【０００２】
ＩｏＴ（ＩｎｔｅｒｎｅｔｏｆＴｈｉｎｇｓ）の発展に伴い、センサなどのデバイスから収集したデータを分析することで付加価値を提供するサービスにビジネス機会があると考えられ、低コストで多種多様の大量データを収集し、データ解析、業務計画改善などを実施する業務アプリケーションが利活用できる形にデータを整形あるいは加工し、提供するデータ処理システムが求められる。【０００３】
近年、工場などデータを収集する現場に設置されるゲートウェイがデータの整形あるいは加工することで、クラウド上のサーバへの通信量削減や、リアルタイムデータ処理を行うエッジコンピューティング技術が普及してきており、データ処理システムを複数のゲートウェイとサーバにより構成するケースが増えてきている。【０００４】
ＩｏＴでのデータ収集では、顧客要件や業務状態の変更により、データ処理を変更することが必要となる。このようなデータ処理の変更を容易にするため、汎用化した複数の処理（処理の実行により実現される機能）を順番に連結してデータ処理を実現することがある。また、データ処理システムを複数のゲートウェイとサーバにより構成した場合、データ処理の変更により、特定のコンポーネントが過負荷となり、システム性能が低下あるいはシステムが停止することがある。【０００５】
これに対し、複数のコンポーネント間で負荷が再配置される技術として、例えば特許文献１には、アーカイブサーバ、エッジサーバ、端末記憶装置のそれぞれにおけるコンテンツを動的かつ最適に再配置することにより、サービス品質の維持およびシステムの効率的運営を実現する技術が開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００４−５３０９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
特許文献１のような再配置の技術は既に存在する。しかしながら、ＩｏＴでのデータ収集におけるデータ処理の変更を容易にするため、複数の処理（機能）を順番に連結してデータ処理を実現した場合、特許文献１に開示されたような技術では、複数の処理の順番を維持したまま、再配置できるとは限らない。【０００８】
本発明の目的は、データに適用する機能の順番を維持したまま、ゲートウェイとサーバとの間で、機能を再配置することにある。
【課題を解決するための手段】
【０００９】
本発明に係る代表的なデータ処理システムは、それぞれが機能を実現する複数の処理を連結するデータ処理システムであって、データを入力するゲートウェイと、前記ゲートウェイから出力されるデータを入力するサーバとを有し、前記ゲートウェイは、第１のフロー情報に含まれる情報にしたがって、入力したデータへ１以上の処理を含む第１の処理を適用して前記サーバへ出力し、前記サーバは、前記第１のフロー情報に含まれる情報にしたがって、前記ゲートウェイから入力したデータへ第２の処理を適用して、その後に１以上の処理を含む第３の処理を適用し、前記第２の処理を特定し、前記サーバが前記ゲートウェイから入力したデータへ前記第３の処理を適用するための情報を含む第２のフロー情報を、前記第１のフロー情報から生成し、前記ゲートウェイが入力したデータへ前記第１の処理を適用してその後に前記第２の処理を適用するための情報を含む前記第２のフロー情報を、前記第１のフロー情報から生成することを特徴とする。
【発明の効果】
【００１０】
本発明によれば、データに適用する機能の順番を維持したまま、ゲートウェイとサーバとの間で、機能を再配置することが可能になる。
【図面の簡単な説明】
【００１１】
【図１Ａ】機能再配置前のデータ処理システムの構成の一例を示す図である。
【図１Ｂ】機能再配置後のデータ処理システムの構成の一例を示す図である。
【図１Ｃ】データ処理システムの構成の一例を示す図である。
【図２】データ処理機能管理テーブルの一例を示す図である。
【図３Ａ】機能再配置前のゲートウェイ機能配置情報テーブルの一例を示す図である。
【図３Ｂ】機能再配置後のゲートウェイ機能配置情報テーブルの一例を示す図である。
【図４Ａ】機能再配置前のＦｌｏｗ定義テーブルの一例を示す図である。
【図４Ｂ】機能再配置後のＦｌｏｗ定義テーブルの一例を示す図である。
【図５Ａ】機能再配置前のゲートウェイ内ルーティングテーブルの一例を示す図である。
【図５Ｂ】機能再配置後のゲートウェイ内ルーティングテーブルの一例を示す図である。
【図６Ａ】機能再配置前のサーバ内ルーティングテーブルの一例を示す図である。
【図６Ｂ】機能再配置後のサーバ内ルーティングテーブルの一例を示す図である。
【図７Ａ】機能再配置前のゲートウェイＣＰＵ情報テーブルの一例を示す図である。
【図７Ｂ】機能再配置後のゲートウェイＣＰＵ情報テーブルの一例を示す図である。
【図８Ａ】機能再配置前のサーバＣＰＵ情報テーブルの一例を示す図である。
【図８Ｂ】機能再配置後のサーバＣＰＵ情報テーブルの一例を示す図である。
【図９Ａ】機能再配置前のプロセス管理テーブルの一例を示す図である。
【図９Ｂ】機能再配置後のプロセス管理テーブルの一例を示す図である。
【図１０】機能の配置を変更する処理の一例を示すフローチャートである。
【図１１】機能をゲートウェイに移動可能か判定する処理の一例を示すフローチャートである。
【図１２】機能を移動するためのテーブルを準備する処理の一例を示すフローチャートである。
【発明を実施するための形態】
【００１２】
以下、図面を用いて、本発明に係るデータ処理システムにおけるデータ処理機能の再配置の実施例について説明する。
【００１３】
＜実施例におけるデータ処理機能の再配置の概要＞
本実施例では、データ処理システムにおけるデータ処理機能の再配置の例について説明する。具体的には、データ処理機能を有する複数のゲートウェイと、同じくデータ処理機能を有するサーバからなるデータ処理システムにおいて、状況の変化に応じて、ゲートウェイおよびサーバで実行するデータ処理機能を変更する動作例を示す。
【００１４】
状況の変化の例として、あるセンサが異常を検知して、定常時よりも多くのセンサデータを送信する状態へ変化する例や、顧客のデータ解析目的の変化に応じて、データ処理の内容や、データ解析に使用するセンサデータの種類や数を変更するといった例が挙げられる。
【００１５】
なお、データ処理機能はデータ処理モジュールの動作により実現される機能である。データ処理モジュールはプログラムを実行するＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）であってもよく、ＣＰＵはプログラムをプロセス（インスタンス）として実行することにより、データ処理機能を実現してもよい。ＣＰＵは１つのプログラムを基に同じ処理の複数のプロセスを生成してもよい。データ処理機能を単に機能と呼ぶこともある。
【００１６】
また、データ処理モジュールはハードウェアモジュールであってもよく、ハードウェアモジュールは例えばＦＰＧＡ（ＦｉｅｌｄＰｒｏｇｒａｍｍａｂｌｅＧａｔｅＡｒｒａｙ）などであってもよい。ハードウェアモジュールの場合、同じ回路の複数のハードウェアモジュールが有ってもよく、複数のハードウェアモジュールが実行されてもよい。
【００１７】
このような同じ回路の複数のハードウェアモジュールをまとめて１つのデータ処理モジュールと呼んでもよく、１つのハードウェアモジュールの実行は、１つのデータ処理の実行であり、１つのプロセスの実行と呼んでもよい。
【００１８】
本実施例を説明する図に関して、図１Ａ、３Ａ、４Ａ、５Ａ、６Ａ、７Ａ、８Ａ、および９Ａは、機能再配置前の状態を示し、図１Ｂ、３Ｂ、４Ｂ、５Ｂ、６Ｂ、７Ｂ、８Ｂ、および９Ｂは、機能再配置後の状態を示す。
【００１９】
本実施例では、あるセンサが異常を検知して、定常時よりも多くのセンサデータを送信する状態へ変化したことにより、サーバのＣＰＵ負荷が増大した状況を機能再配置前とし、サーバからゲートウェイにデータ処理機能を移動（再配置）することで、サーバのＣＰＵ負荷を削減した状態を機能再配置後とする。機能再配置前に対して機能再配置後の差分箇所は、図１Ｂなどの機能再配置後の各図において下線を引いた箇所である。
【００２０】
＜システム構成図＞
図１Ｃは、本実施例に係るデータ処理システムの構成の一例を示す図である。データ処理システムは、サーバ１０と、ゲートウェイ２０−１とを有し、センサ３０−１とセンサ３０−２からセンサデータを収集し、データ処理の結果を業務アプリケーション４０へ送信する。なお、以下では構成要素の全体については「−」以降の数字を省略した符号を使用し、個々の構成要素を特定する場合には「−」以降の数字を加えた符号を用いる。
【００２１】
センサ３０は、例えば、温度センサや、湿度センサや、振動センサといったセンシングデバイスであり、一定時間毎に測定値をセンサデータとしてネットワークに送信する。センサ３０の数は３個以上であってもよい。センサ３０−１は「Ａ１１」というセンサＩＤ（Ｉｄｅｎｔｉｆｉｅｒ）が付与され、センサ３０−２は「Ｂ２１」というセンサＩＤが付与されている。以下で説明する図面には括弧でＩＤを記載する。
【００２２】
ゲートウェイ２０−１は、センサ３０からセンサデータを受信し、受信したセンサデータを処理し、処理したセンサデータをサーバ１０へ送信する。ゲートウェイ２０−１以外のゲートウェイが存在し、ゲートウェイは複数であってもよい。ゲートウェイ２０−１は「Ｇ１」というＩＤが付与されており、センサデータを処理する機能を有する。
【００２３】
センサデータなどを処理するために、ゲートウェイ２０−１はＣＰＵ２０５と記憶装置２０６を備え、記憶装置２０６に格納されたプログラムをＣＰＵ２０５が実行し、記憶装置２０６に格納されたセンサデータなどのデータを処理する。この処理によりゲートウェイ２０−１は、センサ３０からセンサデータをインターフェイス２０７で受信する。
【００２４】
センサデータの種別（センサ３０−１であるかセンサ３０−２であるか）によって、ゲートウェイ２０−１の処理内容は異なるため、ゲートウェイ２０−１のＣＰＵ２０５は、ゲートウェイ内振分プログラム２０１ｂを実行して、センサデータの種別に応じて適用する機能を決定する。このとき、ゲートウェイ内振分プログラム２０１ｂを実行するＣＰＵ２０５は、ゲートウェイ内振分部となる。
【００２５】
適用される機能は、プロセス６０ｂにより実現される機能であり、機能に対応するプログラムであるモジュール８０ｂからプロセス６０ｂがＣＰＵ２０５により生成される。プロセス６０ｂにより出力されるセンサデータは、インターフェイス２０７からネットワーク５０を介して、サーバ１０へ送信される。
【００２６】
また、ゲートウェイ２０−１は、ゲートウェイ２０−１のＣＰＵ２０５の負荷を監視し、サーバ１０に定期的に通知する。このためにＣＰＵ２０５はゲートウェイ内負荷監視プログラム２０２ｂを実行する。このとき、ゲートウェイ内負荷監視プログラム２０２ｂを実行するＣＰＵ２０５は、ゲートウェイ内負荷監視部となる。
【００２７】
図１Ｃにおいて、実線は物理的な通信路であり、点線は論理的な通信路である。以上ではＣＰＵ２０５の処理として説明したが、ゲートウェイ内振分プログラム２０１ｂを実行するＣＰＵ２０５の代わりにゲートウェイ内振分部というハードウェアが有ってもよく、ゲートウェイ内負荷監視プログラム２０２ｂを実行するＣＰＵ２０５の代わりにゲートウェイ内負荷監視部というハードウェアが有ってもよい。
【００２８】
さらに、ＣＰＵ２０５により実行されるプロセス６０ｂの代わりにプロセスという名称のハードウェアが有ってもよい。この場合、ゲートウェイ内負荷監視部はプロセスという名称のハードウェアの負荷を監視してもよく、モジュール８０ｂはプロセスとして動作するためのハードウェアであるが、停止しているハードウェアであってもよい。
【００２９】
サーバ１０は、ゲートウェイ２０−１からセンサデータを受信し、受信したセンサデータを処理し、処理したセンサデータを業務アプリケーション４０へ送信する。サーバ１０は複数のゲートウェイからセンサデータを受信してもよい。センサデータなどを処理するために、サーバ１０はＣＰＵ１０５と記憶装置１０６を備え、記憶装置１０６に格納されたプログラムをＣＰＵ１０５が実行し、記憶装置２０６に格納されたセンサデータおよびテーブルに格納されたデータを処理する。
【００３０】
この処理によりサーバ１０は、ゲートウェイ２０−１からセンサデータをインターフェイス１０７で受信する。センサデータ種別と送信元ゲートウェイによって、サーバ１０の処理内容は異なるため、サーバ１０のＣＰＵ１０５は、サーバ内振分プログラム１０１ａを実行して、センサデータ種別と送信元ゲートウェイに応じて適用する機能を決定する。このとき、サーバ内振分プログラム１０１ａを実行するＣＰＵ１０５は、サーバ内振分部となる。
【００３１】
適用される機能は、プロセス６０ａにより実現される機能であり、プログラムであるモジュール８０ａからプロセス６０ａはＣＰＵ１０５により生成される。プロセス６０ａにより出力されるセンサデータは、インターフェイス１０７から業務アプリケーション４０へ送信される。
【００３２】
センサデータを処理する機能のそれぞれは「Ｆｉ」（「ｉ」は機能の種類に対応する変数）というＩＤが付与され、サーバ１０は、ゲートウェイあるいはサーバで使用可能な機能を「Ｆｉ」に基づいて管理する。このためにサーバ１０は、ゲートウェイあるいはサーバで使用可能な機能の情報が格納されたデータ処理機能管理テーブル１１を有する。
【００３３】
サーバ１０は、複数のゲートウェイそれぞれに配置した機能の情報が格納されたゲートウェイ機能配置情報テーブル１２を有し、ゲートウェイに配置する機能を管理する。サーバ１０と複数のゲートウェイからなるデータ処理システムは、多種多様なデータの処理を柔軟に実現するために、特定のデータの処理を一つの機能として実装するのではなく、汎用化した複数の機能を連結することで、特定のデータ処理を実現する。
【００３４】
例えば、振動センサのデータを高速フーリエ変換して、変換後の値をしきい値判定することで、機器の異常を検知する処理の場合、高速フーリエ変換の機能と、しきい値判定の機能の２つの機能を連結することで、振動センサのデータの処理を構成する。このように処理を、汎用化した機能に分解することで、高速フーリエ変換後にフィルタリングする処理、しきい値判定後にインデックスデータを付与するといった異なる処理も、容易に実現することができる。
【００３５】
サーバ１０とゲートウェイそれぞれの中で、受信したセンサデータに対して適用する一連のプロセスをＦｌｏｗと定義する。サーバ１０はサーバ１０内で実行中のＦｌｏｗを管理し、各ゲートウェイは各ゲートウェイ内で実行中のＦｌｏｗを管理し、サーバ１０は両方のＦｌｏｗを管理するためにＦｌｏｗ定義テーブル１３を有する。
【００３６】
また、サーバ１０は、各ゲートウェイにおけるセンサデータの種別とそのセンサデータに適用するＦｌｏｗとの対応を管理するためにゲートウェイ内ルーティングテーブル１４を有し、サーバ１０におけるセンサデータの種別とそのセンサデータに適用するＦｌｏｗとの対応を管理するためにサーバ１０サーバ内ルーティングテーブル１５を有する。
【００３７】
また、サーバ１０は、ゲートウェイそれぞれのデータ処理負荷の状況を監視するために、各ゲートウェイのＣＰＵ負荷情報を保持するゲートウェイＣＰＵ情報テーブル１６を有し、サーバ１０のデータ処理負荷の状況を監視するために、サーバ１０のＣＰＵ負荷情報を保持するサーバＣＰＵ情報テーブル１７を有する。
【００３８】
また、サーバ１０は、サーバ１０内の各プロセスのＣＰＵ負荷を監視するために、プロセス毎のＣＰＵ負荷情報を保持するプロセス管理テーブル１８を有する。
【００３９】
ここで、プロセスのそれぞれには「Ｆｉ−ｊ」というＩＤが付与される。既に説明したように、各プロセスは各機能の実行単位であり、例えばＩＤが「Ｆｉ−ｊ」というプロセスはＩＤが「Ｆｉ」という機能の実行単位であり、「ｉ」は機能の種類に対応する変数である。同一の機能の実行単位となるプロセスが複数存在する場合もあり、「ｊ」は機能の複製数を示す変数であって、ｊ番目のプロセスであることを示す。
【００４０】
例えば、温度センサのセンサデータをしきい値判定するＦｌｏｗと、湿度センサのデータをしきい値判定する別のＦｌｏｗが実行中の場合、しきい値判定のプロセスは２個存在することになる。しきい値判定の機能のＩＤを「Ｆ２」とする場合、２個のプロセスのＩＤは「Ｆ２−１」と「Ｆ２−２」になる。
【００４１】
サーバ１０は、サーバ１０内のＣＰＵ負荷情報を取得するため、ＣＰＵ１０５がサーバ内負荷監視プログラム１０３ａを実行する。ＣＰＵ１０５は取得したＣＰＵ負荷情報をサーバＣＰＵ情報テーブル１７とプロセス管理テーブル１８に格納する。このとき、サーバ内負荷監視プログラム１０３ａを実行するＣＰＵ１０５は、サーバ内負荷監視部となる。
【００４２】
サーバ１０とゲートウェイ２０−１とはネットワーク５０を介して接続される。ネットワーク５０は、広域ネットワークでもよいし、ローカルネットワークでもよく、ネットワークの種類とネットワークによる接続距離は問わない。
【００４３】
また、サーバ１０とゲートウェイ２０−１とは１つの装置であってもよい。例えば、サーバ１０とゲートウェイ２０−１とは１つのサーバあるいはコンピュータであって、記憶装置１０６に格納されたプログラムおよびデータ（テーブル）と、記憶装置２０６に格納されたプログラムおよびデータとが１つの記憶装置に格納され、１つのＣＰＵにより処理されてもよい。
【００４４】
この１つのＣＰＵは、複数のコアあるいは複数のＣＰＵから構成されてもよい。そして、サーバ１０の処理とゲートウェイ２０−１の処理とには別のコアあるいは別のＣＰＵが割り当てられてもよい。サーバ１０の処理とゲートウェイ２０−１の処理のそれぞれは、別の仮想マシンで実行されてもよい。
【００４５】
図１Ａと図１Ｂは、サーバ１０、ゲートウェイ２０−１、ゲートウェイ２０−２、およびゲートウェイ２０−３を含むデータ処理システム１の例を示す図である。図１Ａと図１Ｂに示したサーバ１０は、図１Ｃを用いて説明したサーバ１０であり、サーバ内振分プログラム１０１ａを実行するＣＰＵ１０５がサーバ内振分部１０１となり、機能配置プログラム１０２ａを実行するＣＰＵ１０５が機能配置部１０２となる。
【００４６】
図１Ａまたは図１Ｂに示したサーバ１０内のプロセス６２−１からプロセス６５−２は、図１Ｃを用いて説明したプロセス６０ａであり、括弧内に各プロセスのＩＤを示す。プロセス６２−１からプロセス６５−２は、１つまたは２つの連結により、Ｆｌｏｗ７１、Ｆｌｏｗ７２、Ｆｌｏｗ７２−１、またはＦｌｏｗ７２−２を構成する。
【００４７】
図１Ａと図１Ｂに示したゲートウェイ２０−１、ゲートウェイ２０−２、およびゲートウェイ２０−３のそれぞれは、図１Ｃを用いて説明したゲートウェイ２０−１と同じ構造を有し、ゲートウェイ内振分プログラム２０１ｂを実行するＣＰＵ２０５がゲートウェイ内振分部２０１−１、ゲートウェイ内振分部２０１−２、およびゲートウェイ内振分部２０１−３のそれぞれとなる。
【００４８】
図１Ａと図１Ｂに示したセンサ３０−１からセンサ３０−６のそれぞれは、図１Ｃを用いて説明したセンサ３０のいずれかと同じ構造であってもよい。このため、センサ３０−１からセンサ３０−６の全体もセンサ３０と記載する。また、ゲートウェイ２０とゲートウェイ内振分部２０１についても同じように記載する。
【００４９】
図１Ａまたは図１Ｂに示したゲートウェイ２０のいずれかに含まれるプロセス６１−１からプロセス６４−３は、図１Ｃを用いて説明したプロセス６０ｂであり、括弧内に各プロセスのＩＤを示す。
【００５０】
図１Ａと図１Ｂに示した各プロセスの配置については、後で説明する。また、図１Ｃを用いて説明した構成であるが、その各プロセスの配置において直接的には言及する必要のない構成（記憶装置１０６など）は、図１Ａと図１Ｂでは図示を省略する。
【００５１】
＜各テーブルの説明＞
以下では、サーバ１０が保持するテーブルのそれぞれについて、テーブルに含まれる情報を説明する。機能再配置前のテーブルに含まれる情報と機能再配置後のテーブルに含まれる情報との相違については後で説明する。
【００５２】
図２は、データ処理機能管理テーブル１１の一例を示す図である。データ処理機能管理テーブル１１は、サーバ１０およびゲートウェイで実現可能な機能を管理するためのテーブルであり、フィールドとして、データ処理機能ＩＤ１１１、処理内容１１２、およびゲートウェイでの実行可否１１３を有する。
【００５３】
データ処理機能ＩＤ１１１のフィールドには機能のＩＤが格納される。処理内容１１２のフィールドには、機能を実現するための処理に関する情報が格納され、図２では理解しやすいように「データ形式変換」などとしているが、これに限定されるものではなく、例えば機能の処理名称を表す他の情報が格納されてもよい。また、機能を実現するプログラムモジュールのファイル名、プログラムコード、あるいはプログラムコードへのポインタが格納されてもよい。
【００５４】
データ処理機能管理テーブル１１を用いて管理される機能の中には、サーバ１０のみでしか実現できない機能がある。別の言い方をすると、データ処理機能管理テーブル１１を用いて管理される機能は、サーバ１０で実現可能な機能であり、ゲートウェイ２０で実現できるとは限らない。
【００５５】
ゲートウェイでの実行可否１１３のフィールドには、ゲートウェイ２０で実現可能であるか否かに応じて「可」あるいは「不可」の情報が格納される。例えば、データ処理機能ＩＤ１１１で「Ｆ６」の処理内容１１２が「複数センサ比較」は、複数のゲートウェイ２０のセンサから収集したセンサデータを比較する処理であり、複数のゲートウェイ２０のセンサデータを集約するサーバ１０でしか実行できず、ゲートウェイ２０では実行できないため、ゲートウェイでの実行可否１１３のフィールドに「不可」が格納されている。
【００５６】
なお、既に説明したように、プロセスの実行により機能が実現されるため、ゲートウェイでの実行可否１１３の「可」と「不可」という情報は、その情報に対応するプロセスのゲートウェイ２０での実行可否も表すことになる。
【００５７】
また、データ処理機能管理テーブル１１のテーブルとしての行（例えば２行目の「Ｆ２」と「しきい値判定」と「可」が関連付けられた情報）を、以下ではエントリと呼び、図２の例で１行目の「Ｆ１」と「データ形式変換」と「可」が関連付けられた情報を、先頭エントリと呼ぶ。また、他のテーブルの行もエントリと呼ぶ。
【００５８】
図３Ａと図３Ｂは、ゲートウェイ機能配置情報テーブル１２の一例を示す図である。ゲートウェイ機能配置情報テーブル１２は、ゲートウェイ２０のそれぞれで実現される機能を管理するためのテーブルであり、フィールドとして、ゲートウェイＩＤ１２１と配置機能ＩＤリスト１２２を有する。
【００５９】
ゲートウェイＩＤ１２１のフィールドにはゲートウェイ２０それぞれのＩＤが格納される。配置機能ＩＤリスト１２２のフィールドには、ゲートウェイ２０のそれぞれで実現される機能のＩＤが格納される。
【００６０】
ここで、ゲートウェイ２０で実現される機能は、その機能を実現するプロセスが生成された状態（実行中あるいは実行可能な状態）を表す。これに対して、データ処理機能管理テーブル１１のゲートウェイでの実行可否１１３のフィールドの「可」は、プロセスが生成された状態に加えて、プロセスが生成される前のプロセス生成可能（生成されれば実行可能）である状態も含む。
【００６１】
図４Ａと図４Ｂは、Ｆｌｏｗ定義テーブル１３の一例を示す図である。Ｆｌｏｗ定義テーブル１３は、サーバ１０とゲートウェイ２０のそれぞれで実行されるＦｌｏｗを管理するためのテーブルである。複数の機能を連結したＦｌｏｗの実行は、Ｆｌｏｗに含まれる機能を実現するプロセスの実行である。このため、Ｆｌｏｗは、Ｆｌｏｗに含まれる機能のＩＤの「Ｆｉ」に対して、プロセスのＩＤである「Ｆｉ−ｊ」のリストとして定義される。
【００６２】
Ｆｌｏｗ定義テーブル１３は、フィールドとして、配置場所１３１、ＦｌｏｗＩＤ１３２、およびプロセスリスト１３３を有する。配置場所１３１のフィールドにはＦｌｏｗがサーバ１０に配置されているか、あるいはゲートウェイ２０の中のどのゲートウェイに配置されているかの情報が格納される。
【００６３】
図４Ａと図４Ｂの例でサーバ１０に配置されている場合は「Ｓｅｒｖ」が格納され、ゲートウェイ２０に配置されている場合はゲートウェイ機能配置情報テーブル１２のゲートウェイＩＤ１２１に対応するＩＤが格納される。ＦｌｏｗＩＤ１３２のフィールドにはＦｌｏｗのＩＤが格納される。
【００６４】
プロセスリスト１３３のフィールドには、プロセスのＩＤが順番にリストとして格納される。プロセスＩＤには順番があるため、例えば「順番１」の「Ｆ２−１」は先頭のプロセスＩＤ、「順番２」の「Ｆ３−１」は先頭に対して次のプロセスＩＤと呼ぶ。
【００６５】
サーバ１０の機能配置部は、Ｆｌｏｗ定義テーブル１３の情報を、サーバ１０のサーバ内振分部１０１に設定し、ゲートウェイ２０のそれぞれがゲートウェイ内振分部２０１に設定するようにゲートウェイ２０へ送信する。
【００６６】
この代わりに、サーバ１０のＣＰＵ１０５がサーバ内振分プログラム１０１ａを実行してＦｌｏｗ定義テーブル１３の情報を取得してもよい。また、ＣＰＵ１０５が機能配置プログラム１０２ａを実行してＦｌｏｗ定義テーブル１３の情報をゲートウェイ２０へ送信し、ゲートウェイ２０それぞれのＣＰＵ２０５がゲートウェイ内振分プログラム２０１ｂを実行してＦｌｏｗ定義テーブル１３の情報を受信してもよい。
【００６７】
図５Ａと図５Ｂは、ゲートウェイ内ルーティングテーブル１４の一例を示す図である。ゲートウェイ内ルーティングテーブル１４は、ゲートウェイ２０のゲートウェイ内振分部２０１におけるデータ転送規則を管理、制御するためのテーブルである。すなわち、ゲートウェイ内振分部２０１がゲートウェイ内ルーティングテーブル１４の情報を受け取ると、その情報に基づいて、センサ３０からのセンサデータを各ゲートウェイ２０内のプロセスに振り分ける。
【００６８】
ゲートウェイ内ルーティングテーブル１４は、フィールドとして、ゲートウェイＩＤ１４１、センサＩＤ１４２、およびＦｌｏｗＩＤ１４３を有する。ゲートウェイＩＤ１４１のフィールドには、ゲートウェイ機能配置情報テーブル１２のゲートウェイＩＤ１２１に対応するＩＤが格納される。
【００６９】
センサＩＤ１４２のフィールドには、センサ３０のＩＤが格納される。ＦｌｏｗＩＤ１４３のフィールドには、Ｆｌｏｗ定義テーブル１３のＦｌｏｗＩＤ１３２に対応するＩＤが格納される。サーバ１０の機能配置部１０２は、ゲートウェイ内ルーティングテーブル１４の情報を、各ゲートウェイ２０がゲートウェイ内振分部２０１に設定するようにゲートウェイ２０へ送信する。
【００７０】
図６Ａと図６Ｂは、サーバ内ルーティングテーブル１５の一例を示す図である。サーバ内ルーティングテーブル１５は、サーバ１０のサーバ内振分部１０１におけるデータ転送規則を管理、制御するためのテーブルである。すなわち、サーバ内振分部１０１がサーバ内ルーティングテーブル１５の情報を受け取ると、その情報に基づいて、ゲートウェイ２０からのセンサデータをサーバ１０内のプロセスに振り分ける。
【００７１】
このために、ゲートウェイ２０からサーバ１０へ送信されるセンサデータには、送信したゲートウェイ２０それぞれのＩＤと、そのセンサデータの送信元であるセンサ３０それぞれのＩＤ（センサデータの種別）が付与される。
【００７２】
サーバ内ルーティングテーブル１５は、フィールドとして、送信元ゲートウェイＩＤ１５１、センサＩＤ１５２、ＦｌｏｗＩＤ１５３、およびトラフィック量１５４を有する。送信元ゲートウェイＩＤ１５１のフィールドには、ゲートウェイ内ルーティングテーブル１４のゲートウェイＩＤ１４１に対応するＩＤであって、センサデータに付与されたセンサデータを送信した各ゲートウェイ２０のＩＤと比較されるＩＤが格納される。
【００７３】
センサＩＤ１５２のフィールドには、ゲートウェイ内ルーティングテーブル１４のセンサＩＤ１４２に対応するＩＤであって、センサデータに付与されたセンサデータの送信元であるセンサのＩＤと比較されるＩＤが格納される。
【００７４】
ＦｌｏｗＩＤ１５３のフィールドには、Ｆｌｏｗ定義テーブル１３のＦｌｏｗＩＤ１３２のＩＤに対応するＩＤであって、配置場所１３１が「Ｓｅｒｖ」すなわちサーバ１０内のＦｌｏｗのＩＤが格納される。
【００７５】
トラフィック量１５４のフィールドには、サーバ１０内のＦｌｏｗ毎に測定されたセンサデータのトラフィック量が例えば「Ｍｂｐｓ」の単位で格納される。トラフィック量１５４のフィールドに格納される情報は、定期的に更新されてもよいし、センサデータのトラフィック量の変化するイベントが存在するのであれば、そのイベントを検出したタイミングで更新されてもよい。
【００７６】
サーバ１０の機能配置部１０２は、サーバ内ルーティングテーブル１５の情報を、サーバ１０内のサーバ内振分部１０１に設定する。この代わりに、サーバ１０のＣＰＵ１０５がサーバ内振分プログラム１０１ａを実行してサーバ内ルーティングテーブル１５の情報を取得してもよい。
【００７７】
図７Ａと図７Ｂは、ゲートウェイＣＰＵ情報テーブル１６の一例を示す図である。ゲートウェイＣＰＵ情報テーブル１６は、サーバ１０が、ゲートウェイ２０それぞれのＣＰＵ負荷を監視するために使用するテーブルである。ここで、ＣＰＵ負荷は例えば図１ＣにおけるＣＰＵ２０５の負荷である。
【００７８】
ゲートウェイＣＰＵ情報テーブル１６は、フィールドとして、ゲートウェイＩＤ１６１、ＣＰＵ負荷１６２、および対サーバ性能比１６３を有する。ゲートウェイＩＤ１６１のフィールドには、ゲートウェイ内ルーティングテーブル１４のゲートウェイＩＤ１４１に対応するＩＤが格納される。
【００７９】
ＣＰＵ負荷１６２のフィールドには、例えばＣＰＵ負荷の最大限界を１００％として、測定時点でのＣＰＵ負荷の比率が格納される。対サーバ性能比１６３のフィールドには、例えば予め測定されたサーバ１０のＣＰＵ１０５の性能に対するゲートウェイ２０それぞれのＣＰＵ２０５の性能の比率が格納される。
【００８０】
図８Ａと図８Ｂは、サーバＣＰＵ情報テーブル１７の一例を示す図である。サーバＣＰＵ情報テーブル１７は、サーバ１０が、サーバ１０のＣＰＵ負荷を監視するために使用するテーブルである。ここで、ＣＰＵ負荷は例えば図１ＣにおけるＣＰＵ１０５の負荷である。サーバＣＰＵ情報テーブル１７は、フィールドとしてＣＰＵ負荷１７１を有し、例えばＣＰＵ負荷の最大限界を１００％として、測定時点でのＣＰＵ負荷の比率が格納される。
【００８１】
図９Ａと図９Ｂは、プロセス管理テーブル１８の一例を示す図である。プロセス管理テーブル１８は、サーバ１０が、サーバ１０内の各プロセスのＣＰＵ負荷を監視するために使用するテーブルであり、フィールドとして、プロセスＩＤ１８１とＣＰＵ負荷１８２を有する。
【００８２】
プロセスＩＤ１８１のフィールドには、Ｆｌｏｗ定義テーブル１３において配置場所１３１が「Ｓｅｒｖ」であるプロセスリスト１３３のフィールドに格納されたプロセスのＩＤが格納される。ＣＰＵ負荷１８２のフィールドには、プロセスＩＤ１８１のフィールドに格納されたＩＤのプロセスを実行する際のＣＰＵ負荷が格納される。
【００８３】
＜データ処理システムにおけるセンサデータを処理する場所と順番の例＞
図１Ａを用いて、データ処理システム１におけるセンサ３０から業務アプリケーション４０までのセンサデータを処理する場所と順番の例を説明する。
【００８４】
例として、図１Ａにおいて、センサ３０−１は、自身のセンサＩＤである「Ａ１１」とセンサ値を格納したセンサデータをゲートウェイ２０−１に送信する。ここで、センサデータはセンサＩＤとセンサ値以外の情報を含んでもよく、センサ値を測定した時刻を示すタイムスタンプデータを含んでもよい。
【００８５】
センサ３０−１からのセンサデータを受信したゲートウェイ２０−１は、以下で説明するように、ゲートウェイ内振分部２０１−１において、受信したセンサデータに適用するデータ処理のＦｌｏｗを設定、すなわちセンサデータをプロセスに振り分ける。
【００８６】
ゲートウェイ内振分部２０１−１は、サーバ１０が有するゲートウェイ内ルーティングテーブル１４−１のゲートウェイＩＤ１４１−１が「Ｇ１」のエントリの情報が設定されている。この設定された情報を用いて、受信したセンサデータのセンサＩＤが「Ａ１１」であるため、センサＩＤ１４２−１で「Ａ１１」と一致するＦｌｏｗＩＤ１４３−１の「３０１」を取得する。
【００８７】
また、ゲートウェイ内振分部２０１−１には、サーバ１０が有するＦｌｏｗ定義テーブル１３−１の配置場所１３１−１が「Ｇ１」の情報が設定されている。この設定された情報を用いて、ＦｌｏｗＩＤ１３２−１で「３０１」と一致するプロセスリスト１３３−１の「Ｆ１−１」を取得する。
【００８８】
取得した「Ｆ１−１」にしたがって、ゲートウェイ内振分部２０１−１は受信したセンサデータをプロセス６１−１へ振り分け、プロセス６１−１はセンサデータを処理し、ゲートウェイ２０−１は、処理後のセンサデータ、ゲートウェイＩＤとして「Ｇ１」、センサＩＤとして「Ａ１１」をペイロードに格納したパケットをサーバ１０に送信する。
【００８９】
ゲートウェイ２０−１からのセンサデータを受信したサーバ１０は、以下で説明するように、サーバ内振分部１０１において、受信したセンサデータに適用するデータ処理のＦｌｏｗを設定、すなわちセンサデータをプロセスに振り分ける。
【００９０】
サーバ１０のサーバ内振分部１０１は、サーバ内ルーティングテーブル１５−１の情報が設定されており、送信元ゲートウェイＩＤ１５１−１が「Ｇ１」で一致し、センサＩＤ１５２−１が「Ａ１１」で一致するため、適用するＦｌｏｗのＩＤとしてＦｌｏｗＩＤ１５３−１の「１０１」を取得する。
【００９１】
また、サーバ内振分部１０１は、Ｆｌｏｗ定義テーブル１３−１の配置場所１３１−１が「Ｓｅｒｖ」の情報が設定されている。この設定された情報を用いて、ＦｌｏｗＩＤ１３２−１で「１０１」と一致するプロセスリスト１３３−１の「Ｆ２−１」と「Ｆ３−１」をこれらのプロセスＩＤの順番と共に取得する。
【００９２】
この取得した「Ｆ２−１」と「Ｆ３−１」にしたがって、サーバ内振分部１０１は受信したセンサデータをＦｌｏｗ７１（プロセス６２−１）へ振り分け、最初にプロセス６２−１が受信したセンサデータを処理し、次にプロセス６３−１がプロセス６２−１から出力されたセンサデータを処理して、処理後のセンサデータをペイロードに格納したパケットを業務アプリケーション４０に送信する。
【００９３】
センサＩＤがそれぞれ「Ａ２１」と「Ａ３１」であるセンサ３０−３とセンサ３０−５のセンサデータも、サーバ１０においては、ＦｌｏｗＩＤ１５３−１が「１０１」であり、Ｆｌｏｗ７１に振り分けられる。
【００９４】
また、センサＩＤがそれぞれ「Ｂ１２」と「Ｂ２２」と「Ｂ３２」であるセンサ３０−２とセンサ３０−４とセンサ３０−６は、サーバ１０において、ＦｌｏｗＩＤ１５３−１が「１０２」であり、ＦｌｏｗＩＤ１３２−１で「１０２」と一致するプロセスリスト１３３−１の「Ｆ４−１」と「Ｆ５−１」にしたがって、サーバ内振分部１０１によりＦｌｏｗ７２（プロセス６４−１）に振り分けられる。
【００９５】
なお、以上で説明したように、Ｆｌｏｗ定義テーブル１３、ゲートウェイ内ルーティングテーブル１４、およびサーバ内ルーティングテーブル１５によって、センサデータを処理する場所と順番が決まるため、これらのテーブルの情報をまとめてフロー情報と呼んでもよい。
【００９６】
＜機能の配置を変更する処理の例＞
図１０は、サーバ１０の機能配置部１０２が機能の配置を変更するためのフローチャートの例を示す図である。機能配置部１０２は、サーバ１０のＣＰＵ負荷が予め設定された値を超える度に、このフローチャートを実行する。なお、以下で、機能配置部１０２を主語とする説明は、機能配置プログラム１０２ａを実行するＣＰＵ１０５を主語にした説明に代えてもよい。
【００９７】
機能配置部１０２は、サーバ内ルーティングテーブル１５の先頭エントリを参照して、送信元ゲートウェイＩＤ１５１とＦｌｏｗＩＤ１５３のフィールドの情報を取得し（ステップＳ１０１）、取得したＦｌｏｗＩＤをキーとして、Ｆｌｏｗ定義テーブル１３を参照し、ＦｌｏｗＩＤ１３２でキーと一致するエントリのプロセスリスト１３３のフィールドのプロセスＩＤを取得する（ステップＳ１０２）。
【００９８】
機能配置部１０２は、取得したプロセスＩＤの中の先頭のプロセスＩＤを取得する（ステップＳ１０３）。先頭のプロセスＩＤを取得する理由は、本データ処理システム１でのデータ処理では、各Ｆｌｏｗにおける機能（プロセス）の順番は定められており、機能の順番を維持する必要がある。このため、サーバ１０からゲートウェイ２０に移動する機能の候補は、サーバ１０内の各Ｆｌｏｗの先頭のプロセスとなる。
【００９９】
次に、機能配置部１０２は、取得したプロセスＩＤ（Ｆｉ−ｊ）の機能（Ｆｉ）が、取得した（送信元の）ゲートウェイＩＤのゲートウェイ２０に移動可能かどうかを判定する（ステップＳ１０４）。ここで、ステップＳ１０３の次にステップＳ１０４が実行される場合は、取得したプロセスＩＤはステップＳ１０３で取得したプロセスＩＤであり、取得したゲートウェイＩＤはステップＳ１０１で取得したゲートウェイＩＤである。
【０１００】
この判定には、データ処理機能管理テーブル１１のゲートウェイでの実行可否１１３のフィールドの情報に基づく判定と、ゲートウェイ２０のＣＰＵ負荷に対するＣＰＵ能力の余剰量に基づく判定とがあり、判定の結果は移動可能か移動不可かの判定値となるが、詳細は図１１に示すフローチャートを用いて後で説明する。
【０１０１】
機能配置部１０２は、判定値が移動可能かどうかを判定し（ステップＳ１０５）、移動可能と判定した場合（ステップＳ１０５：ＹＥＳ）、ステップＳ１０６を実行する。ステップＳ１０６で機能配置部１０２は、移動可能と判定された機能を移動した後のＦｌｏｗ定義テーブル１３、ゲートウェイ内ルーティングテーブル１４、およびサーバ内ルーティングテーブル１５の変更の準備を行う（ステップＳ１０６）。この準備については図１２に示すフローチャートを用いて後で説明する。
【０１０２】
そして、機能配置部１０２は、移動可能と判定された機能を移動した際のサーバ１０のＣＰＵ負荷を算出する（ステップＳ１０７）。算出したサーバのＣＰＵ負荷が目標値ｘ％未満（ｘは予め設定された値）であるかどうかを判定し（ステップＳ１０８）、未満であると判定した場合（ステップＳ１０８：ＹＥＳ）、機能配置部１０２は、ステップＳ１０６での準備に基づき、Ｆｌｏｗ定義テーブル１３、ゲートウェイ内ルーティングテーブル１４、およびサーバ内ルーティングテーブル１５を実際に変更して、移動可能と判定された機能の移動を実施し（ステップＳ１０９）、機能の配置の変更を終了する。
【０１０３】
ステップＳ１０５で機能配置部１０２は、移動不可と判定した場合（ステップＳ１０５：ＮＯ）、移動不可と判定された機能より後の機能が仮に移動可能であるとしても、移動不可と判定されて移動しなかった機能との順番が維持できないため、ステップＳ１１１の次のエントリの判定に進む。
【０１０４】
ステップＳ１０８で機能配置部１０２は、移動可能と判定された機能の移動ではサーバのＣＰＵ負荷が目標値ｘ％未満にならないと判定した場合（ステップＳ１０８：ＮＯ）、ステップＳ１０２で取得したプロセスリストで次のプロセスが存在するかどうか判定し（ステップＳ１１０）、存在すると判定した場合（ステップＳ１１０：ＹＥＳ）、次のプロセスＩＤを取得し（ステップＳ１１３）、取得したプロセスＩＤを用いてステップＳ１０４以下のステップを再試行する。
【０１０５】
ステップＳ１１０で機能配置部１０２は、次のプロセスが存在しないと判定した場合（ステップＳ１１０：ＮＯ）、サーバ内ルーティングテーブル１５の次のエントリが存在するかどうかを判定し、次のエントリが存在すると判定した場合（ステップＳ１１１：ＹＥＳ）、次のエントリを取得し（ステップＳ１１４）、取得したエントリを用いてステップＳ１０２以下のステップを再試行する。
【０１０６】
ステップＳ１１１で機能配置部１０２は、サーバ内ルーティングテーブル１５の次のエントリが存在しないと判定した場合（ステップＳ１１１：ＮＯ）、移動可能な機能の候補がこれ以上存在せず、現状の計算リソースでは機能再配置によるサーバＣＰＵ負荷の削減を図ることができないため、機能の配置を変更せずに処理を終了する。ここで、ステップＳ１０６により準備された情報が有れば、その情報は破棄される。
【０１０７】
＜プロセスＩＤの機能を指定ゲートウェイに移動可能か判定する処理の例＞
図１１は、図１０のステップＳ１０４に示した、プロセスＩＤの機能をゲートウェイに移動可能かの判定の処理を、具体的に示すためのフローチャートである。
【０１０８】
機能配置部１０２が、図１０のステップＳ１０３またはステップＳ１１３で取得したプロセスＩＤ（対象プロセスＩＤ）の機能（対象機能）が、図１０のステップＳ１０１またはステップＳ１１４で取得したエントリの送信元ゲートウェイＩＤ１５１のＩＤが付与されたゲートウェイ（対象ゲートウェイ）に移動可能かどうかを判定する。
【０１０９】
機能配置部１０２は、対象プロセスＩＤ（Ｆｉ―ｊ）から対象機能ＩＤ（Ｆｉ）を抽出し、対象機能ＩＤ（Ｆｉ）をキーとしてデータ処理機能管理テーブル１１を参照し、データ処理機能ＩＤ１１１のフィールドでキーと一致するＩＤに対応するゲートウェイでの実行可否１１３のフィールドが、「可」であるか「不可」であるかを判定する（ステップＳ１０４１）。
【０１１０】
「不可」であると判定した場合（ステップＳ１０４１：ＮＯ）、機能配置部１０２は、「判定値＝移動不可」を返り値に設定して（ステップＳ１０４９）、図１０に示したフローチャートへ戻り、ステップＳ１０５へ進む。
【０１１１】
ステップＳ１０４１で機能配置部１０２は、「可」であると判定した場合（ステップＳ１０４１：ＹＥＳ）、サーバ内ルーティングテーブル１５を参照し、図１０のステップＳ１０１またはステップＳ１１４で取得したエントリの情報の中のＦｌｏｗＩＤ１５３のフィールドのＩＤ（対象ＦｌｏｗＩＤ）を取得し、取得した対象ＦｌｏｗＩＤと同じＩＤのＦｌｏｗの総トラフィック量を計算する。
【０１１２】
そして、機能配置部１０２は、計算した総トラフィック量に対して、取得したエントリの情報の中のトラフィック量１５４のフィールドのトラフィック量（対象ゲートウェイのトラフィック量）の割合Ｙを算出する（ステップＳ１０４２）。
【０１１３】
例えば、対象ＦｌｏｗＩＤが「１０１」の場合、図６ＡでＦｌｏｗＩＤが「１０１」の総トラフィック量は、１０Ｍｂｐｓ＋１６Ｍｂｐｓ＋６Ｍｂｐｓ＝３２Ｍｂｐｓとなる。ここで、ＦｌｏｗＩＤが「１０１」の総トラフィック量に対して、上から３番目のエントリのゲートウェイＩＤが「Ｇ２」（対象ゲートウェイ）、ＦｌｏｗＩＤが「１０１」のトラフィック量の割合Ｙを算出すると、Ｙ＝１６Ｍｂｐｓ÷３２Ｍｂｐｓ＝０．５になる。
【０１１４】
次に、機能配置部１０２は、対象プロセスＩＤをキーに、プロセス管理テーブル１８を参照し、プロセスＩＤ１８１でキーと一致するＩＤに対応するＣＰＵ負荷１８２のフィールドの負荷Ｚ（％）を取得する（ステップＳ１０４３）。
【０１１５】
機能配置部１０２は、ステップＳ１０４３で取得した負荷Ｚ（％）に、ステップＳ１０４２で算出した割合Ｙを乗算することで、（複数のゲートウェイのセンサデータを処理する）対象プロセスＩＤのプロセスにおける対象ゲートウェイのＣＰＵ負荷α（％）を算出する（ステップＳ１０４４）。
【０１１６】
例えば、プロセス（Ｆ２−１）のＣＰＵ負荷の場合、図９ＡでプロセスＩＤが「Ｆ２−１」のＣＰＵ負荷すなわち負荷Ｚは「１０％」であり、割合Ｙは「０．５」であるので、ゲートウェイＩＤが「Ｇ２」の対象ゲートウェイのＣＰＵ負荷α（％）は、α＝Ｚ×Ｙ＝１０％×０．５＝５％になる。
【０１１７】
続いて、機能配置部１０２は、ゲートウェイＣＰＵ情報テーブル１６において、ゲートウェイＩＤ１６１で対象ゲートウェイのＩＤと一致するＩＤに対応するＣＰＵ負荷１６２と対サーバ性能比１６３の情報を取得し（ステップＳ１０４５）、機能を移動した後の対象ゲートウェイのＣＰＵ負荷β（％）を算出する。
【０１１８】
機能配置部１０２は、このＣＰＵ負荷β（％）を（対象ゲートウェイのＣＰＵ負荷）＋（ＣＰＵ負荷α÷対サーバ性能比）により算出し、算出したＣＰＵ負荷β（％）を基に、機能を移動した場合の対象ゲートウェイのＣＰＵ性能の余剰能力を得て、移動可否を判定する（ステップＳ１０４７）。
【０１１９】
このために、機能配置部１０２は、ＣＰＵ負荷β（％）が目標値ｘ％（ｘは予め設定された値）未満であるかどうか判定し、目標値ｘ％未満であると判定した場合（ステップＳ１０４７：ＹＥＳ）、「判定値＝移動可能」を返り値に設定して（ステップＳ１０４８）、図１０に示したフローチャートへ戻り、ステップＳ１０５へ進む。
【０１２０】
また、ステップＳ１０４７で機能配置部１０２は、目標値ｘ％以上であると判定した場合（ステップＳ１０４７：ＮＯ）、「判定値＝移動不可」を返り値に設定して（ステップＳ１０４９）、図１０に示したフローチャートへ戻り、ステップＳ１０５へ進む。
【０１２１】
＜機能を移動するためのＦｌｏｗ定義テーブル１３、ゲートウェイ内ルーティングテーブル１４、およびサーバ内ルーティングテーブル１５の準備の例＞
図１２は、図１０のステップＳ１０６に示した、プロセスＩＤの機能をゲートウェイに移動するための、Ｆｌｏｗ定義テーブル１３、ゲートウェイ内ルーティングテーブル１４、およびサーバ内ルーティングテーブル１５の変更の準備を、具体的に示すためのフローチャートである。
【０１２２】
Ｆｌｏｗ定義テーブル１３、ゲートウェイ内ルーティングテーブル１４、およびサーバ内ルーティングテーブル１５が実際に変更されるのは、図１０に示したステップＳ１０９であり、ステップＳ１１２が実行される場合は、実際の変更は行われることなく準備した情報は破棄される。
【０１２３】
このため、Ｆｌｏｗ定義テーブル１３、ゲートウェイ内ルーティングテーブル１４、およびサーバ内ルーティングテーブル１５のそれぞれは一時的にコピーされて、変更の準備のために用いられるが、以下の説明では、本来のテーブルとの対応を理解しやすいように、変更の準備のための一時的なテーブルに対しても、Ｆｌｏｗ定義テーブル１３、ゲートウェイ内ルーティングテーブル１４、およびサーバ内ルーティングテーブル１５という表現を用いる。
【０１２４】
なお、Ｆｌｏｗ定義テーブル１３、ゲートウェイ内ルーティングテーブル１４、およびサーバ内ルーティングテーブル１５のそれぞれを一時的にコピーせず、情報を参照する場合は本来の各テーブルそれぞれから読み出し、情報を書き換える場合は各テーブルの外の領域に一時的に保存して、この保存した情報を用いてステップＳ１０９で本来のテーブルそれぞれを書き換えるようにしてもよい。
【０１２５】
データ処理システム１は、複数の機能を連結し、連結した機能のプロセスを連結した順番に実行することにより、センサデータを処理するため、機能の順番を維持したまま、機能を移動することが必要となる。
【０１２６】
サーバ１０からゲートウェイ２０に機能を移動するため、機能配置部１０２は、最初にサーバ１０から移動する機能に対応するプロセスを含むＦｌｏｗを特定し、サーバ１０の特定されたＦｌｏｗを変更するための情報を生成する。
【０１２７】
その後、サーバ１０の特定されたＦｌｏｗに関連するゲートウェイ２０のＦｌｏｗを特定し、ゲートウェイ２０の特定されたＦｌｏｗを変更する情報を生成する。このように、機能を移動するために、サーバ１０のＦｌｏｗ、ゲートウェイ２０のＦｌｏｗを順に特定することが本実施例の特徴である。
【０１２８】
以下、具体的な変更の準備の手順を説明する。前提として、図１０に示したフローチャートを用いて説明したように、ステップＳ１０６が実行される時点で、移動する機能のプロセスＩＤと移動先のゲートウェイＩＤが決定されている。
【０１２９】
最初に、機能配置部１０２は、Ｆｌｏｗ定義テーブル１３を参照し、移動する機能のプロセスのＩＤをプロセスリスト１３３に含むエントリのＦｌｏｗＩＤ１３２のＩＤを、サーバ内対象ＦｌｏｗＩＤとして取得する（ステップＳ１０６１）。
【０１３０】
次に、機能配置部１０２は、サーバ内ルーティングテーブル１５において、サーバ内対象ＦｌｏｗＩＤをＦｌｏｗＩＤ１５３に含み、かつ移動先のゲートウェイＩＤを送信元ゲートウェイＩＤ１５１に含むエントリを探索し、探索で見つかったエントリのセンサＩＤ１５２のＩＤを対象センサＩＤとして取得し、見つかったエントリのＦｌｏｗＩＤ１５３のＩＤ（サーバ内対象ＦｌｏｗＩＤ）を新規のＩＤに書き換える（ステップＳ１０６２）。
【０１３１】
機能配置部１０２は、Ｆｌｏｗ定義テーブル１３において、ステップＳ１０６１で取得したサーバ内対象ＦｌｏｗＩＤをＦｌｏｗＩＤ１３２に含むエントリに対し、移動する機能のプロセスＩＤをプロセスリスト１３３から取り除き、ステップＳ１０６２で設定した新規なＩＤをＦｌｏｗＩＤ１３２に設定することにより、移動する機能のプロセスを取り除いたＦｌｏｗを、新規なＩＤのＦｌｏｗとする（ステップＳ１０６３）。
【０１３２】
この際、機能配置部１０２は、新規なＩＤのＦｌｏｗに含まれるプロセス（移動されずに残るプロセス）のプロセスＩＤにも新規のＩＤを設定する。ただし、新規なＩＤのＦｌｏｗを構成するプロセスの機能と同一の機能のプロセスから構成されるＦｌｏｗが、既に存在している場合は、ＦｌｏｗＩＤ１３２とＦｌｏｗＩＤ１５２の新規なＩＤを、既に存在しているＦｌｏｗのＩＤに変更し、そのＦｌｏｗを適用する。
【０１３３】
以上で、Ｆｌｏｗ定義テーブル１３のサーバ分と、サーバ内ルーティングテーブル１５の変更の準備は完了となり、続いて、機能配置部１０２は、Ｆｌｏｗ定義テーブル１３のゲートウェイ分と、ゲートウェイ内ルーティングテーブル１４の変更を準備する。
【０１３４】
機能配置部１０２は、ゲートウェイ内ルーティングテーブル１４において、ステップＳ１０６２で取得した対象センサＩＤをセンサＩＤ１４２に含むエントリのＦｌｏｗＩＤ１４３のＩＤをゲートウェイ内対象ＦｌｏｗＩＤとして取得し、ゲートウェイ内対象ＦｌｏｗＩＤを新規なＩＤに書き換える（ステップＳ１０６４）。
【０１３５】
次に、機能配置部１０２は、Ｆｌｏｗ定義テーブル１３において、ステップＳ１０６４で取得したゲートウェイ内対象ＦｌｏｗＩＤをＦｌｏｗＩＤ１３２に含むエントリに対し、プロセスリスト１３３の順番の最後尾に、サーバ１０から移動する機能のプロセスの新規なＩＤを追加し、ＦｌｏｗＩＤ１３２のゲートウェイ内対象ＦｌｏｗＩＤを新規なＩＤに書き換えることにより、新規なＩＤのプロセスを追加したＦｌｏｗを、新規なＩＤのＦｌｏｗとする（ステップＳ１０６５）。
【０１３６】
ただし、新規なＩＤのＦｌｏｗを構成するプロセスの機能と同一の機能のプロセスから構成されるＦｌｏｗが、既に存在している場合は、ＦｌｏｗＩＤ１３２とＦｌｏｗＩＤ１４３の新規なＩＤを、既に存在しているＦｌｏｗのＩＤに変更し、そのＦｌｏｗを適用する。
【０１３７】
以上で、Ｆｌｏｗ定義テーブル１３のゲートウェイ分と、ゲートウェイ内ルーティングテーブル１４の変更の準備は完了となる。
【０１３８】
図１２を用いて説明したフローチャートによる各テーブルの具体的な内容の例を、先ず、機能（Ｆ４）をサーバ１０からゲートウェイ２０−２に移動する場合の例で説明する。この移動が行われると、サーバ１０のプロセス（Ｆ４−１）の一部が取り除かれ、ゲートウェイ２０−２のプロセス（Ｆ４−２）が追加される。
【０１３９】
なお、ここでも、変更のために準備する一時的にコピーされたテーブルを、Ｆｌｏｗ定義テーブル１３、ゲートウェイ内ルーティングテーブル１４、およびサーバ内ルーティングテーブル１５として説明する。
【０１４０】
最初に、機能配置部１０２は、図４Ａに示したＦｌｏｗ定義テーブル１３−１を参照し、移動する機能（Ｆ４）のプロセスＩＤとして既に取得された「Ｆ４−１」をプロセスリスト１３３−１に含むＦｌｏｗＩＤ１３２−１の「１０２」を取得し、サーバ内対象ＦｌｏｗＩＤ＝１０２とする（ステップＳ１０６１）。
【０１４１】
次に、機能配置部１０２は、サーバ内ルーティングテーブル１５−１において、「１０２」（サーバ内対象ＦｌｏｗＩＤ＝１０２）をＦｌｏｗＩＤ１５３−１に含み、かつ「Ｇ２」（移動先ゲートウェイＩＤ＝Ｇ２）を送信元ゲートウェイＩＤ１５１−１に含むエントリを探索し、探索により見つかったエントリのセンサＩＤ１５２−１の「Ｂ２２」を対象センサＩＤとして取得する。
【０１４２】
そして、機能配置部１０２は、見つかったエントリのサーバ内対象ＦｌｏｗＩＤすなわちＦｌｏｗＩＤ１５３−１の「１０２」を新規なＩＤの「２０１」に書き換える（ステップＳ１０６２）。一部が書き換わった後のサーバ内ルーティングテーブル１５−２の例を図６Ｂは含む。センサＩＤ１５２−２が「Ｂ２２」のエントリのＦｌｏｗＩＤ１５３−２が「２０１」に書き換わっている。
【０１４３】
機能配置部１０２は、Ｆｌｏｗ定義テーブル１３−１において、ＦｌｏｗＩＤ１３２−１が「１０２」（サーバ内対象ＦｌｏｗＩＤ＝１０２）から移動する機能のプロセスＩＤである「Ｆ４−１」をプロセスリスト１３３−１から取り除いたＦｌｏｗを、ステップＳ１０６２で書き換えた新規なＩＤの「２０１」のＦｌｏｗとして設定する（ステップＳ１０６３）。
【０１４４】
一部が書き換わった後のＦｌｏｗ定義テーブル１３−２の例を図４Ｂは含む。ＦｌｏｗＩＤ１３２−２が「２０１」のエントリが追加され、追加されたエントリのプロセスリスト１３３−２には「Ｆ４−１」に対応するプロセスＩＤが取り除かれ、「Ｆ５−１」を新規なＩＤとした「Ｆ５−２」が残っている。また、配置場所１３１−２にはサーバ内対象ＦｌｏｗＩＤ＝１０２と同じ「Ｓｅｒｖ」が設定される。
【０１４５】
続いて、機能配置部１０２は、ゲートウェイ内ルーティングテーブル１４−１において、ステップＳ１０６２で取得した対象センサＩＤの「Ｂ２２」をセンサＩＤ１４２−１に含むエントリのＦｌｏｗＩＤ１４３−１の「４０１」をゲートウェイ内対象ＦｌｏｗＩＤとして取得し、ゲートウェイ内対象ＦｌｏｗＩＤの「４０１」を新規なＩＤの「４０２」に書き換える（ステップＳ１０６４）。
【０１４６】
一部が書き換わった後のゲートウェイ内ルーティングテーブル１４−２の例を図５Ｂは含む。センサＩＤ１４２−２が「Ｂ２２」のエントリのＦｌｏｗＩＤ１４３−２が「４０２」に書き換わっている。
【０１４７】
次に、機能配置部１０２は、Ｆｌｏｗ定義テーブル１３−１において、ＦｌｏｗＩＤ１３２−１が「４０１」（ゲートウェイ内対象ＦｌｏｗＩＤ＝４０１）のエントリのプロセスリスト１３３−１の最後尾に、サーバ１０から移動する機能の新規なプロセスＩＤである「Ｆ４−２」を追加したＦｌｏｗを、ステップＳ１０６４で書き換えた新規なＩＤの「４０２」のＦｌｏｗとして設定する（ステップＳ１０６５）。
【０１４８】
一部が書き換わった後のＦｌｏｗ定義テーブル１３−２の例を図４Ｂは含む。ＦｌｏｗＩＤ１３２−２が「４０２」のエントリが追加され、追加されたエントリのプロセスリスト１３３−２には「Ｆ１−２」を新規なＩＤとした「Ｆ１−４」が残り、「Ｆ４−２」が追加されている。また、配置場所１３１−２にはゲートウェイ内対象ＦｌｏｗＩＤ＝４０１と同じ「Ｇ２」が設定される。
【０１４９】
以上が、機能（Ｆ４）をサーバ１０からゲートウェイ２０−２に移動する場合の各テーブルの例である。次に、機能（Ｆ４）をサーバ１０からゲートウェイ２０−３にさらに移動する場合の各テーブルの例を説明する。
【０１５０】
最初に、機能配置部１０２は、先に説明したステップＳ１０６１と同じくサーバ内対象ＦｌｏｗＩＤ＝１０２とし、先に説明したステップＳ１０６２の「Ｇ２」に代わって「Ｇ３」（移動先ゲートウェイＩＤ＝Ｇ３）を含むエントリを探索して、見つかったエントリの「Ｂ３２」を対象センサＩＤとして取得する。見つかったエントリのサーバ内対象ＦｌｏｗＩＤの新規なＩＤへの書き換えについては次で説明する。
【０１５１】
次に、機能配置部１０２は、「Ｆ４−１」をプロセスリスト１３３−２から取り除いたＦｌｏｗを、新規なＩＤのＦｌｏｗとして設定するのであるが、先に説明したステップＳ１０６３で既にＩＤが「２０１」のＦｌｏｗとして設定されているので、ここでのステップＳ１０６３では設定しない。そして、ここでのステップＳ１０６２での新規なＩＤへの書き換えも「２０１」となる。
【０１５２】
続いて、機能配置部１０２は、先に説明したステップＳ１０６３の「Ｂ２２」に代わって「Ｂ３２」を対象センサＩＤとし、「５０１」をゲートウェイ内対象ＦｌｏｗＩＤとして取得し、「５０１」を新規なＩＤの「５０２」に書き換える。そして、先に説明したステップＳ１０６３と同じように、ＦｌｏｗＩＤ１３２−２が「５０１」のエントリのプロセスリスト１３３−１の最後尾に、移動する機能の新規なプロセスＩＤである「Ｆ４−３」を追加したＦｌｏｗを、新規なＩＤの「５０２」のＦｌｏｗとして設定する。
【０１５３】
最終的に書き換わった後のＦｌｏｗ定義テーブル１３−２の例を図４Ｂに示すと、ＦｌｏｗＩＤ１３２−２が「２０１」、「４０２」、および「５０２」のエントリが追加されている。また、最終的に書き換わった後のゲートウェイ内ルーティングテーブル１４−２の例を図５Ｂに示すと、ＦｌｏｗＩＤ１４３−２で「４０２」と「５０２」に書き換わっている。また、最終的に書き換わった後のサーバ内ルーティングテーブル１５−２の例を図６Ｂに示すと、ＦｌｏｗＩＤ１５３−２で「２０１」に書き換わっている。
【０１５４】
機能の移動に伴い、機能配置部１０２は、図３Ａに示したゲートウェイ機能配置情報テーブル１２−１を更新する。具体的には、図３Ｂに示したゲートウェイ機能配置情報テーブル１２−２のように、ゲートウェイＩＤ１２１−２の「Ｇ２」と「Ｇ３」のエントリそれぞれの配置機能ＩＤリスト１２２−２に「Ｆ４」が追加される。
【０１５５】
また、機能配置部１０２は、図９Ａに示したプロセス管理テーブル１８−１も更新する。具体的には、図９Ｂに示したプロセス管理テーブル１８−２のように、プロセスＩＤ１８１−２が「Ｆ５−２」のエントリが追加される。
【０１５６】
また、機能の移動に伴い、サーバ１０、ゲートウェイ２０−２、およびゲートウェイ２０−３のＣＰＵ負荷が変化する。例えば、図７Ａに示したゲートウェイＣＰＵ情報テーブル１６−１は図７Ｂに示したゲートウェイＣＰＵ情報テーブル１６−２のようになり、ゲートウェイＩＤ１６１−２が「Ｇ２」と「Ｇ３」それぞれのエントリのＣＰＵ負荷１６２−２の値が増加する。
【０１５７】
これに対して、図８Ａに示したサーバＣＰＵ情報テーブル１７−１は図８Ｂに示したサーバＣＰＵ情報テーブル１７−２のようになり、ＣＰＵ負荷１７１−２の値が減少して、サーバ１０の負荷が軽減すると共に、データ処理システム１としてのＣＰＵ負荷が平準化されてことになる。
【０１５８】
サーバ１０のプロセス毎のＣＰＵ負荷の内訳としては、図８Ａに示したプロセス管理テーブル１８−１が図８Ｂに示したプロセス管理テーブル１８−２のようになり、プロセスＩＤ１８１−２が「Ｆ４−１」のエントリのＣＰＵ負荷１８２−２の値が減少し、プロセスＩＤ１８１−１が「Ｆ５−１」のエントリのＣＰＵ負荷１８２−１の値は、プロセスＩＤ１８１−２が「Ｆ５−１」と「Ｆ５−２」それぞれのエントリのＣＰＵ負荷１８２−２の値に分散する。
【０１５９】
図１Ｂを用いて、図１Ａに対する、以上で説明した各テーブルを反映したプロセスの配置の例を説明する。図１Ｂに示すように、ゲートウェイ２０−２に機能（Ｆ４）が移動して来てプロセス６１−４とプロセス６４−２が追加され、ゲートウェイ２０−３に機能（Ｆ４）が移動して来てプロセス６１−５とプロセス６４−３が追加される。
【０１６０】
また、サーバ１０から機能（Ｆ４）の一部が移動して、サーバ１０にプロセス６５−２が追加される。Ｆｌｏｗ７１は図１Ａを用いて説明したとおりであるが、Ｆｌｏｗ７２は、センサ３０−２のセンサデータに対するＦｌｏｗ７２−１と、センサ３０−４およびセンサ３０−６のセンサデータに対するＦｌｏｗ７２−２とに振り分けられる。
【０１６１】
＜本実施例の効果＞
状況に応じて、データ処理の機能の実行箇所を動的に変更することにより、サーバやゲートウェイの計算リソースを追加することなく、現存の計算リソース量で対応することができ、データ処理の計算リソースにかかるコストを抑制することができる。
【０１６２】
なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に記載したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。
【０１６３】
また、上記の各構成、機能、処理部、及び処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、及び機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。
【０１６４】
各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（ＳｏｌｉｄＳｔａｔｅＤｒｉｖｅ）等の記録装置、または、フラッシュメモリのカード、光ディスク等の記録媒体に置くことができる。
【０１６５】
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていてもよい。
【符号の説明】
【０１６６】
１      データ処理システム
１０    サーバ
２０    ゲートウェイ
３０    センサ
１０１  サーバ内振分部
１０２  機能配置部
２０１  ゲートウェイ内振分部
【図１Ａ】
0006705942.tif 000002
【図１Ｂ】
0006705942.tif 000003
【図１Ｃ】
0006705942.tif 000004
【図２】
0006705942.tif 000005
【図３Ａ】
0006705942.tif 000006
【図３Ｂ】
0006705942.tif 000007
【図４Ａ】
0006705942.tif 000008
【図４Ｂ】
0006705942.tif 000009
【図５Ａ】
0006705942.tif 000010
【図５Ｂ】
0006705942.tif 000011
【図６Ａ】
0006705942.tif 000012
【図６Ｂ】
0006705942.tif 000013
【図７Ａ】
0006705942.tif 000014
【図７Ｂ】
0006705942.tif 000015
【図８Ａ】
0006705942.tif 000016
【図８Ｂ】
0006705942.tif 000017
【図９Ａ】
0006705942.tif 000018
【図９Ｂ】
0006705942.tif 000019
【図１０】
0006705942.tif 000020
【図１１】
0006705942.tif 000021
【図１２】
0006705942.tif 000022