(57)【要約】【課題】故障した機器で実行されていたソフトウェアを代替の機器に容易に導入できるようにする。【解決手段】情報処理装置１０は、複数の機器が多階層に接続されたシステム内の第１機器の下位の階層の機器として、第１機器に第２機器が接続されたことを検知する。次に情報処理装置１０は、複数の機器間の接続関係を示す接続情報１に基づいて、第１機器に接続されている、第２機器と同じ階層の第３機器を検出する。次に情報処理装置１０は、第３機器の監視結果に基づいて、第３機器の障害の有無を判定する。そして情報処理装置１０は、第３機器に障害が発生している場合、複数の機器それぞれに配信済みのソフトウェアを示すソフトウェア情報２に基づいて、第３機器に配信済みのソフトウェアを第２機器に配信する。【選択図】図１
2020149480.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータに、
複数の機器が多階層に接続されたシステム内の第１機器の下位の階層の機器として、前記第１機器に第２機器が接続されたことを検知し、
前記複数の機器間の接続関係を示す接続情報に基づいて、前記第１機器に接続されている、前記第２機器と同じ階層の第３機器を検出し、
前記第３機器の監視結果に基づいて、前記第３機器の障害の有無を判定し、
前記第３機器に障害が発生している場合、前記複数の機器それぞれに配信済みのソフトウェアを示すソフトウェア情報に基づいて、前記第３機器に配信済みのソフトウェアを前記第２機器に配信する、
処理を実行させるソフトウェア配信プログラム。
【請求項２】
前記第１機器への前記第２機器の接続の検知では、前記第２機器から前記第１機器へ出力された接続要求メッセージを、前記第１機器から取得したとき、前記第２機器が接続されたと検知する、
請求項１記載のソフトウェア配信プログラム。
【請求項３】
前記コンピュータに、さらに、
前記接続要求メッセージに基づいて、前記第１機器と前記第２機器との接続関係を前記接続情報に追加する、
処理を実行させる請求項２記載のソフトウェア配信プログラム。
【請求項４】
前記第３機器の障害の有無の判定では、前記第１機器による前記第３機器の状態の監視により前記第１機器が前記第３機器の障害を検知したときに前記第１機器が送出する障害発生通知メッセージを取得したか否かに基づいて、前記第３機器の障害の有無を判定する、
請求項１ないし３のいずれかに記載のソフトウェア配信プログラム。
【請求項５】
コンピュータが、
複数の機器が多階層に接続されたシステム内の第１機器の下位の階層の機器として、前記第１機器に第２機器が接続されたことを検知し、
前記複数の機器間の接続関係を示す接続情報に基づいて、前記第１機器に接続されている、前記第２機器と同じ階層の第３機器を検出し、
前記第３機器の監視結果に基づいて、前記第３機器の障害の有無を判定し、
前記第３機器に障害が発生している場合、前記複数の機器それぞれに配信済みのソフトウェアを示すソフトウェア情報に基づいて、前記第３機器に配信済みのソフトウェアを前記第２機器に配信する、
ソフトウェア配信方法。
【請求項６】
複数の機器が多階層に接続されたシステムにおける前記複数の機器間の接続関係を示す接続情報と、前記複数の機器それぞれに配信済みのソフトウェアを示すソフトウェア情報とを記憶する記憶部と、
前記システム内の第１機器の下位の階層の機器として、前記第１機器に第２機器が接続されたことを検知し、前記接続情報に基づいて、前記第１機器に接続されている、前記第２機器と同じ階層の第３機器を検出し、前記第３機器の監視結果に基づいて、前記第３機器の障害の有無を判定し、前記第３機器に障害が発生している場合、前記ソフトウェア情報に基づいて、前記第３機器に配信済みのソフトウェアを前記第２機器に配信する処理部と、
を有する情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェア配信プログラム、ソフトウェア配信方法、および情報処理装置に関する。
【背景技術】
【０００２】
現在、ＩＣＴ（Information and Communication Technology）システムの大きな潮流として、ＩｏＴ（Internet of Things）が注目を浴びており、様々な分野においてＩｏＴ実現に向けた技術開発が行われ、新サービスが立ち上がってきている。ＩｏＴとは、従来はインターネットに直接接続されてこなかった機器やモノが、それ自身がインターネットに接続できるようになることである。例えば、従来から、コンピュータやモバイル端末などの人間が操作する情報通信機器はインターネットに接続されている。これらの機器に加え、ＩｏＴでは、センサや計測器機器、家電や制御機器、さらにはＲＦＩＤ（Radio Frequency IDentifier）などによってタグ付けされた物品までも、インターネットに接続される。
【０００３】
ＩｏＴを用いたサービスを実現するシステム（ＩｏＴシステム）は、様々な機器によって構成される分散処理システムであり、それらの機器が連携動作することでＩｏＴを用いたサービスが実現される。各機器には、その機器に実行させる処理に対応するアプリケーションソフトウェアがインストールされる。以下、アプリケーションソフトウェアを単に「アプリ」と呼ぶこともある。ＩｏＴを用いたサービスの提供用のアプリ（ＩｏＴアプリ）は、ＩｏＴシステムに含まれる機器に、その機器に割り当てられたデータ処理を実行させるためのソフトウェアである。各機器が、その機器に割り当てられたデータ処理を実行することで、複数の機器による連係動作が可能となる。
【０００４】
このような分散処理システムでのソフトウェア開発に有用な技術としては、例えば実行モジュールを実行するノードを動的に決定することでシステム全体として効率的な処理が可能な分散システムがある。またＩｏＴに関する技術として、ネットワーク内のノードが、ネットワーク内の他のノードがスリーピ（スリープモードになり得ること）であることを決定する技術もある。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】国際公開第２０１６／２０７９８９号
【特許文献２】国際公開第２０１５／００６６３６号
【発明の概要】
【発明が解決しようとする課題】
【０００６】
機器が故障した場合、システムの管理者は、故障した機器で実行しているソフトウェアを代替の機器に導入し、代替の機器でソフトウェアを実行させることとなる。しかし、大規模なシステムにおいて、システム内の多数の機器の中からの代替の機器の選択や、代替の機器へのソフトウェアの導入の作業を人手で行っていたのでは、作業に時間がかかる。そのため、故障した機器で実行していたソフトウェアを用いたサービスの停止時間も長期化してしまう。特にＩｏＴシステムのような分散処理システムでは、一部の機器の故障によりサービス全体が停止する場合があり、故障した機器で実行していたソフトウェアの代替の機器への導入を迅速に行うことは、システムの安定運用のためにも重要である。
【０００７】
１つの側面では、本件は、故障した機器で実行されていたソフトウェアを代替の機器に容易に導入できるようにすることを目的とする。
【課題を解決するための手段】
【０００８】
１つの案では、以下の処理をコンピュータに実行させるソフトウェア配信プログラムが提供される。
コンピュータは、複数の機器が多階層に接続されたシステム内の第１機器の下位の階層の機器として、第１機器に第２機器が接続されたことを検知する。次にコンピュータは、複数の機器間の接続関係を示す接続情報に基づいて、第１機器に接続されている、第２機器と同じ階層の第３機器を検出する。次にコンピュータは、第３機器の監視結果に基づいて、第３機器の障害の有無を判定する。そしてコンピュータは、第３機器に障害が発生している場合、複数の機器それぞれに配信済みのソフトウェアを示すソフトウェア情報に基づいて、第３機器に配信済みのソフトウェアを第２機器に配信する。
【発明の効果】
【０００９】
１態様によれば、故障した機器で実行されていたソフトウェアを代替の機器に容易に導入可能となる。
【図面の簡単な説明】
【００１０】
【図１】第１の実施の形態に係るソフトウェア配信方法の一例を示す図である。
【図２】ＩｏＴシステムの構成の一例を示す図である。
【図３】ネットワークトポロジの一例を示す図である。
【図４】アプリ開発サーバのハードウェアの一構成例を示す図である。
【図５】アプリ開発サーバの機能の一例を示すブロック図である。
【図６】デバイス情報記憶部の一例を示す図である。
【図７】全体アプリフローデータ記憶部の一例を示す図である。
【図８】配備済みアプリ記憶部の一例を示す図である。
【図９】機器接続情報記憶部の一例を示す図である。
【図１０】配備先機器状態記憶部の一例を示す図である。
【図１１】配備先機器の機能の一例を示すブロック図である。
【図１２】下流機器情報記憶部の一例を示す図である。
【図１３】分配アプリの自動生成および配備処理の一例を示す図である。
【図１４】分配アプリの生成および配備手順を示すフローチャートである。
【図１５】分配アプリ生成処理の手順の一例を示すフローチャートである。
【図１６】システム構築フェーズにおける機器接続情報の更新例を示す図である。
【図１７】新規に接続された配備先機器による接続要求メッセージ送信処理の手順の一例を示すフローチャートである。
【図１８】配備先機器による接続要求メッセージ転送処理の手順の一例を示すフローチャートである。
【図１９】マスタによる接続機器登録処理の手順の一例を示すフローチャートである。
【図２０】配備先機器の障害検知例を示す図である。
【図２１】上流機器による下流機器状態確認処理の手順の一例を示すフローチャートである。
【図２２】下流機器における状態通知処理の手順の一例を示すフローチャートである。
【図２３】マスタにおける障害状態判定処理の手順の一例を示すフローチャートである。
【図２４】アプリ再配備例を示す図である。
【図２５】アプリ再配備処理の手順の一例を示すフローチャートである。
【発明を実施するための形態】
【００１１】
以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第１の実施の形態〕
図１は、第１の実施の形態に係るソフトウェア配信方法の一例を示す図である。図１には、ソフトウェア配信方法を情報処理装置１０によって実施した場合の例を示している。情報処理装置１０は、例えばソフトウェア配信方法の処理手順が記述されたソフトウェア配信プログラムを実行することにより、ソフトウェア配信方法を実施することができる。
【００１２】
情報処理装置１０は、ソフトウェア配信方法を実現するために、記憶部１１と処理部１２とを有する。記憶部１１は、例えば情報処理装置１０が有するメモリ、またはストレージ装置である。処理部１２は、例えば情報処理装置１０が有するプロセッサ、または演算回路である。
【００１３】
情報処理装置１０は、複数の機器３ａ〜３ｅが多階層に接続されたシステムに、ネットワークで接続されている。複数の機器３ａ〜３ｅは、例えば情報処理装置１０から配信されたソフトウェアを実行することにより、所定の機能を実現するサーバである。図１の例では、情報処理装置１０が最上位の階層の機器（マスタ）であり、情報処理装置１０の下位の階層に機器３ａと機器３ｂとがある。機器３ａ，３ｂの下位の階層には、機器３ａに接続された機器３ｃと機器３ｂに接続された機器３ｄ，３ｅとがある。複数の機器３ａ〜３ｅそれぞれには、機器名が付与されている。例えば機器３ａの機器名は「Ａ」、機器３ｂの機器名は「Ｂ」、機器３ｃの機器名は「Ｃ」、機器３ｄの機器名は「Ｄ」、機器３ｅの機器名は「Ｅ」である。
【００１４】
情報処理装置１０内の記憶部１１は、接続情報１とソフトウェア情報２とを記憶する。接続情報１は、複数の機器３ａ〜３ｅ間の接続関係を示す情報である。ソフトウェア情報２は、複数の機器３ａ〜３ｅそれぞれに配信済みのソフトウェアを示す情報である。
【００１５】
情報処理装置１０内の処理部１２は、複数の機器が多階層に接続されたシステム内の第１機器の下位の階層の機器として、第１機器に第２機器が接続されたことを検知する（ステップＳ１）。例えば処理部１２は、第２機器から第１機器へ出力された接続要求メッセージを、第１機器から取得したとき、第２機器が接続されたと検知する。図１の例では、機器３ｅが新たに接続された場合を想定している。この場合、処理部１２は、機器３ｅから機器３ｂ宛てに送信した接続要求メッセージを、機器３ｂから取得する。そして処理部１２は、接続要求メッセージに基づいて、機器３ｂの下位の階層の機器として、機器３ｅが機器３ｂに接続されたことを認識する。なお処理部１２は、接続要求メッセージに基づいて、第１機器と第２機器との接続関係を接続情報１に追加してもよい。
【００１６】
次に処理部１２は、接続情報１に基づいて、第１機器に接続されている、第２機器と同じ階層の第３機器を検出する（ステップＳ２）。例えば処理部１２は、接続情報１に基づいて、機器３ｂの下位の階層として機器３ｂに接続されている機器３ｄを、第３機器として検出する。
【００１７】
次に処理部１２は、第３機器の監視結果に基づいて、第３機器の障害の有無を判定する（ステップＳ３）。例えば処理部１２は、第１機器による第３機器の状態の監視により第１機器が第３機器の障害を検知したときに、第１機器が送出する障害発生通知メッセージを取得したか否かに基づいて、第３機器の障害の有無を判定する。図１の例では、機器３ｄに障害が発生している。機器３ｄの状態は、機器３ｄの上位の階層において機器３ｄに接続されている機器３ｂが監視する。機器３ｂは、機器３ｄに障害が発生したことを検知すると、機器３ｄにおける障害発生を示す障害発生通知メッセージを、情報処理装置１０に送信する。情報処理装置１０の処理部１２は、受信した障害発生通知メッセージに基づいて、機器３ｄにおける障害発生を認識する。
【００１８】
処理部１２は、第３機器に障害が発生している場合、ソフトウェア情報２に基づいて、第３機器に配信済みのソフトウェアを第２機器に配信する（ステップＳ４）。図１の例では、ソフトウェア情報２には、第３機器である機器３ｄの配信済みソフトウェアとして、ソフトウェア「ａｐｐ２」が示されている。そこで処理部１２は、ソフトウェア「ａｐｐ２」を、新たに接続された機器３ｅに送信する。機器３ｅは、送信されたソフトウェア「ａｐｐ２」を実行することで、そのソフトウェア「ａｐｐ２」に応じた機能を実現する。
【００１９】
このような情報処理装置１０を利用すれば、障害が発生した機器が接続されている上位の機器に代替の機器が接続されると、障害が発生した機器に配信済みのソフトウェアが、自動で代替の機器に配信される。これにより、故障した機器で実行されていたソフトウェアを代替の機器に容易に導入できる。すなわち、システムの管理者は、障害が発生した機器が接続されている上位の階層の機器に、代替の機器を接続することで、故障した機器が実行していた機能を実現するためのソフトウェアを代替の機器に実行させることができる。その結果、機器の故障により停止していたサービスを、迅速に復旧させることができる。
【００２０】
しかも、情報処理装置１０は、機器間の階層的な接続関係を考慮して、故障した機器の代替の機器を特定している。そのため代替の機器を適切に判断することができる。すなわち複数の機器を含むシステムでは、一連の処理を分散処理させるために、互いに連係するソフトウェアが異なる機器に配布される場合がある。この場合、機器間のネットワークの位置関係が機器間の通信速度に影響をおよぼす。そのため情報処理装置１０は、機器間の接続関係を考慮した適切な機器に、個々の処理を実行するソフトウェアが配布される。このようなソフトウェアの配布が行われているときに一部の機器に障害が発生すると、障害が発生した機器の代替機器は、ネットワーク上での位置が、障害が発生した機器と同等となるように、システムの管理者によってネットワークに接続される。情報処理装置１０は、障害が発生した機器とネットワーク上の位置が同等となる機器を、障害が発生した機器の代替の機器と判断して、ソフトウェアを自動配信する。すなわち情報処理装置１０は、代替の機器を適切に判断して、ソフトウェアの自動配信を行っている。
【００２１】
なお機器３ａ〜３ｅの多階層の接続関係は、例えばツリー型のネットワークトポロジで表すことができる。ツリー型のネットワークトポロジでは、マスタまでの距離により、各機器の属する階層が表される。各機器のマスタまでの距離は、機器とマスタとの間に存在する他の機器の数である。マスタに近い機器ほど上位層となる。
【００２２】
〔第２の実施の形態〕
次に第２の実施の形態について説明する。第２の実施の形態は、複数の機器で構成される分散環境上で動作するＩｏＴ向けアプリを実行するサーバが故障した場合に、故障したサーバで実行しているアプリを代替サーバに自動で配備（デプロイ）できるようにしたものである。なおＩｏＴアプリを配備するとは、ＩｏＴアプリを機器に送信し、ＩｏＴアプリを機器にインストールし、機器にＩｏＴアプリの実行を開始させることである。
【００２３】
例えばＩｏＴ向けアプリ開発者がＩｏＴアプリを開発する際に、個別の機器ごとにアプリ開発や配備を行うのは、非常に手間がかかる作業となる。そこで第２の実施の形態では、開発者がアプリ開発用サーバを用いて分散機器全体に渡るアプリを定義した後、アプリ開発用サーバは、個別機器間で一意な経路を持つような通信処理部を備えた、各機器に対応したＩｏＴアプリを自動生成し、配備する。これにより機器毎に対応するアプリを開発する作業を削減することを可能としている。
【００２４】
例えばアプリ開発サーバは生成アプリを配備する機器を事前に指定することで、定義した全体アプリから各配備先となる機器ごとの分配アプリを生成する。機器が故障した状況で代わりの機器を接続した場合、アプリ開発サーバは、接続した機器のみに適切な分配アプリ（故障した機器に配備していたアプリ）を配備する。
【００２５】
なお、機器の入れ替え、追加を行う際に、再度全体アプリに対する変換を行い、該当アプリの配備先の機器すべてに対して分配アプリを配備していたのでは、既に動いている機器のアプリも入れ替えることになり、運用中の対応が困難となる。また全体アプリから生成されたすべての分配アプリを再配備すると、その間、サービスを停止することとなり、利用者の利便性の低下を招く。
【００２６】
そこで、第２の実施の形態では、アプリ開発サーバは、分配アプリを実行しているサーバが故障した場合、そのサーバで実行している分配アプリを自動で他の代替サーバに配備する。これにより、サーバが故障しても、故障によるサービスへの悪影響を最小限に抑えることができる。
【００２７】
図２は、ＩｏＴシステムの構成の一例を示す図である。ＩｏＴシステムは、様々な機器を用いて構築される。例えばＩｏＴシステムには、センサ３１，３２，・・・、およびセンサ３１，３２，・・・と接続してセンサデータの送受信を行うセンサノード４１，４２，・・・が含まれる。また、ＩｏＴシステムには、センサノードとクラウドコンピューティングシステムとの間でデータを中継するＧＷ（ゲートウェイ）ノード５１が含まれる。ＧＷノード５１は、例えばネットワーク２０を介してクラウドコンピューティングシステムに接続される。
【００２８】
クラウドコンピューティングシステムは、複数のサーバ５２，５３，・・・を含んでいる。サーバ５２，５３，・・・には、Ｗｅｂサーバ、アプリケーションサーバ、データベースサーバなどの、各種サーバが含まれる。
【００２９】
さらにネットワーク２０には、複数の端末装置６１，６２，・・・が接続されている。端末装置６１，６２，・・・は、例えばパーソナルコンピュータ、またはモバイル端末装置である。
【００３０】
ネットワーク２０には、さらにアプリ開発サーバ１００が接続されている。アプリ開発サーバ１００は、ＩｏＴシステムに含まれる複数の機器それぞれに実行させる分配アプリを作成し、分配アプリを各機器に配備する。以下、分配アプリの配備先となり得る機器を、配備先機器と呼ぶ。図２の例では、センサノード４１，４２，・・・、ＧＷノード５１、サーバ５２，５３，・・・、端末装置６１，６２，・・・それぞれが、配備先機器である。
【００３１】
例えばアプリ開発サーバ１００は、分散機器環境上で動作するＩｏＴアプリの生成および配備を、フローベースのアプリケーション開発環境を用いて実施する。ＩｏＴアプリには、例えばアプリレイヤ上のデータ処理、およびサービス提供処理を、配備先の機器に実行させるための命令が記述されている。フローベースのアプリケーション開発環境により生成されるＩｏＴアプリは、アプリフローで表される。アプリフローでは、機能に対応するノードとノード間を接続する線により、ＩｏＴシステムに処理を実行させるための機能と、処理の手順とが表される。ノードは、機能ブロックに対して、その機能ブロックに対応する機能に実行させる処理の定義情報（パラメータなど）を付加したものである。
【００３２】
アプリの開発者がアプリフローを作成すると、アプリ開発サーバ１００が、アプリフローに示される機能と処理の手順とを実現するプログラム（全体アプリフローデータ）を自動生成する。さらにアプリ開発サーバ１００は、機能ごとの分散処理を実現する場合、全体アプリフローデータに基づいて、配備先機器ごとに、該当配備先機器に実施させる機能と処理の手順とを実現するプログラム（分配アプリフローデータ）を生成する。その際、アプリ開発サーバ１００は、分配アプリフローデータに基づく機能（分配アプリ）間での通信機能を、分配アプリに含める。
【００３３】
例えばアプリ開発サーバ１００は、通信に高いセキュリティが求められる場合には、高いセキュリティ機能を備えた通信プロトコルによる通信機能を、分配アプリに含める。高いセキュリティ機能を備えた通信プロトコルとしては、例えばＨＴＴＰＳ（Hypertext Transfer Protocol Secure）のような認証や暗号化技術を用いたＨＴＴＰ（Hypertext Transfer Protocol）がある。またアプリ開発サーバ１００は、高い処理効率が求められる場合には、効率的な通信が可能な通信プロトコルによる通信機能を、分配アプリに含める。効率的な通信が可能な通信プロトコルとしては、例えばＭＱＴＴ（Message Queue Telemetry Transport）がある。ＭＱＴＴは、ＨＴＴＰに比べてヘッダサイズが非常に小さく、通信量や送受信する機器の負荷を低く抑えることができる。アプリ開発サーバ１００は、分配アプリフローデータを配備先機器に配備することで、ＩｏＴアプリを複数の配備先機器により分散処理させることができる。
【００３４】
システム内のアプリ開発サーバ１００と配備先機器との接続関係は、例えば、アプリ開発サーバ１００をルートとする木構造のネットワークトポロジとなっている。
図３は、ネットワークトポロジの一例を示す図である。ネットワークトポロジ７０において、アプリ開発サーバ１００がマスタ７１となる。図３の例では、マスタ７１には配備先機器７２〜７４が接続されている。配備先機器７２には、さらに配備先機器７５が接続されている。配備先機器７３には、さらに配備先機器７６，７７が接続されている。配備先機器７５には、さらに配備先機器７８が接続されている。配備先機器７２の機器名は「Ａ」、配備先機器７３の機器名は「Ｂ」、配備先機器７４の機器名は「Ｃ」、配備先機器７５の機器名は「Ｄ」、配備先機器７６の機器名は「Ｅ」、配備先機器７７の機器名は「Ｆ」、配備先機器７８の機器名は「Ｇ」である。
【００３５】
以下の説明では、ネットワークトポロジ７０においてマスタ７１に近い方を上流、マスタ７１から遠い方を下流と呼ぶ。ある配備先機器に着目したとき、着目した配備先機器の上流側に隣接する他の配備先機器を、着目した配備先機器の上流機器と呼ぶ。また着目した配備先機器の下流側に隣接する他の配備先機器を、着目した配備先機器の下流機器と呼ぶ。例えば配備先機器７５の上流機器は、配備先機器７２である。また配備先機器７５の下流機器は、配備先機器７８である。
【００３６】
なお図３に示したネットワークトポロジ７０は、ツリー型のトポロジである。ネットワークトポロジ７０で接続されている機器の間には、スイッチなどの通信機器が介在している場合もある。なおネットワークトポロジ７０は、例えば機器間の物理的な接続関係を示す物理トポロジである。またネットワークトポロジ７０は、アプリ開発サーバ１００との間の通信経路を定義した理論上の装置間の接続関係を示す論理トポロジであってもよい。
【００３７】
配備先機器７２〜７８となるＧＷノード５１やサーバ５２，５３，・・・は、ネットワークトポロジ７０における上流機器および下流機器と通信することで、システム上での自己の存在をマスタ７１として機能するアプリ開発サーバ１００に認識させる。
【００３８】
なお、センサノード４１，４２，・・・、ＧＷノード５１、サーバ５２，５３，・・・、端末装置６１，６２，・・・、およびアプリ開発サーバ１００は、例えばコンピュータによって実現される。
【００３９】
図４は、アプリ開発サーバのハードウェアの一構成例を示す図である。アプリ開発サーバ１００は、プロセッサ１０１によって装置全体が制御されている。プロセッサ１０１には、バス１０９を介してメモリ１０２と複数の周辺機器が接続されている。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、またはＤＳＰ（Digital Signal Processor）である。プロセッサ１０１がプログラムを実行することで実現する機能の少なくとも一部を、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現してもよい。
【００４０】
メモリ１０２は、アプリ開発サーバ１００の主記憶装置として使用される。メモリ１０２には、プロセッサ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションソフトウェアの少なくとも一部が一時的に格納される。また、メモリ１０２には、プロセッサ１０１による処理に利用する各種データが格納される。メモリ１０２としては、例えばＲＡＭ（Random Access Memory）などの揮発性の半導体記憶装置が使用される。
【００４１】
バス１０９に接続されている周辺機器としては、ストレージ装置１０３、グラフィック処理装置１０４、入力インタフェース１０５、光学ドライブ装置１０６、機器接続インタフェース１０７およびネットワークインタフェース１０８がある。
【００４２】
ストレージ装置１０３は、内蔵した記録媒体に対して、電気的または磁気的にデータの書き込みおよび読み出しを行う。ストレージ装置１０３は、コンピュータの補助記憶装置として使用される。ストレージ装置１０３には、ＯＳのプログラム、アプリケーションソフトウェア、および各種データが格納される。なお、ストレージ装置１０３としては、例えばＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）を使用することができる。
【００４３】
グラフィック処理装置１０４には、モニタ２１が接続されている。グラフィック処理装置１０４は、プロセッサ１０１からの命令に従って、画像をモニタ２１の画面に表示させる。モニタ２１としては、有機ＥＬ（Electro Luminescence）を用いた表示装置や液晶表示装置などがある。
【００４４】
入力インタフェース１０５には、キーボード２２とマウス２３とが接続されている。入力インタフェース１０５は、キーボード２２やマウス２３から送られてくる信号をプロセッサ１０１に送信する。なお、マウス２３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。
【００４５】
光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク２４に記録されたデータの読み取りを行う。光ディスク２４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク２４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。
【００４６】
機器接続インタフェース１０７は、アプリ開発サーバ１００に周辺機器を接続するための通信インタフェースである。例えば機器接続インタフェース１０７には、メモリ装置２５やメモリリーダライタ２６を接続することができる。メモリ装置２５は、機器接続インタフェース１０７との通信機能を搭載した記録媒体である。メモリリーダライタ２６は、メモリカード２７へのデータの書き込み、またはメモリカード２７からのデータの読み出しを行う装置である。メモリカード２７は、カード型の記録媒体である。
【００４７】
ネットワークインタフェース１０８は、ネットワーク２０に接続されている。ネットワークインタフェース１０８は、ネットワーク２０を介して、他のコンピュータまたは通信機器との間でデータの送受信を行う。
【００４８】
アプリ開発サーバ１００は、以上のようなハードウェア構成によって、第２の実施の形態の処理機能を実現することができる。また、センサノード４１，４２，・・・、ＧＷノード５１、サーバ５２，５３，・・・、および端末装置６１，６２，・・・も、アプリ開発サーバ１００と同様のハードウェアにより実現することができる。さらに、第１の実施の形態に示した情報処理装置１０も、図４に示したアプリ開発サーバ１００と同様のハードウェアにより実現することができる。
【００４９】
アプリ開発サーバ１００は、例えばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第２の実施の形態の処理機能を実現する。アプリ開発サーバ１００に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。例えば、アプリ開発サーバ１００に実行させるプログラムをストレージ装置１０３に格納しておくことができる。プロセッサ１０１は、ストレージ装置１０３内のプログラムの少なくとも一部をメモリ１０２にロードし、プログラムを実行する。またアプリ開発サーバ１００に実行させるプログラムを、光ディスク２４、メモリ装置２５、メモリカード２７などの可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばプロセッサ１０１からの制御により、ストレージ装置１０３にインストールされた後、実行可能となる。またプロセッサ１０１が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。
【００５０】
次に、アプリ開発サーバ１００の機能について説明する。
図５は、アプリ開発サーバの機能の一例を示すブロック図である。アプリ開発サーバ１００は、デバイス情報記憶部１１０、全体アプリフローデータ記憶部１２０、配備済みアプリ記憶部１３０、機器接続情報記憶部１４０、配備先機器状態記憶部１５０、配備指示部１６１、全体アプリフロー編集部１６２、分配アプリ生成部１６３、分配アプリ配備部１６４、機器経路情報登録部１７１、機器接続検知部１７２、障害状態判定部１７３、配備アプリ判定部１７４、および配備済みアプリ再配備部１７５を有する。
【００５１】
デバイス情報記憶部１１０は、ＩｏＴシステムに含まれる配備先機器についての情報を記憶する。例えばデバイス情報記憶部１１０として、メモリ１０２またはストレージ装置１０３の記憶領域の一部が使用される。
【００５２】
全体アプリフローデータ記憶部１２０は、ＩｏＴシステムに実行させる処理を、単一の機器に実行させた場合の処理手順を示すデータ（全体アプリフローデータ）を記憶する。例えば全体アプリフローデータ記憶部１２０として、メモリ１０２またはストレージ装置１０３の記憶領域の一部が使用される。
【００５３】
配備済みアプリ記憶部１３０は、全体アプリフローデータに基づいて生成され、いずれかの機器に配備された分配アプリフローデータを記憶する。例えば配備済みアプリ記憶部１３０として、メモリ１０２またはストレージ装置１０３の記憶領域の一部が使用される。
【００５４】
機器接続情報記憶部１４０は、ネットワークトポロジ７０における機器の接続情報を記憶する。例えば機器接続情報記憶部１４０として、メモリ１０２またはストレージ装置１０３の記憶領域の一部が使用される。
【００５５】
配備先機器状態記憶部１５０は、配備先機器の状態を記憶する。配備先機器の状態は、例えば分配アプリの配備状態や障害発生状態である。例えば配備先機器状態記憶部１５０として、メモリ１０２またはストレージ装置１０３の記憶領域の一部が使用される。
【００５６】
配備指示部１６１は、全体アプリフローに基づく分配アプリの生成、および分配アプリの配備を制御する。例えば配備指示部１６１は、全体アプリフロー編集部１６２から全体アプリフローデータ１２１を受け取ると、全体アプリフローデータ１２１を全体アプリフローデータ記憶部１２０に格納する。また配備指示部１６１は、アプリ開発者からの、全体アプリフローに含まれる各ノードに対応する機能の配備先である配備先機器の指定入力を受け付ける。この指定入力の受け付けは、例えば画面に表示された配備先機器のリストの中から、アプリ開発者に配備先機器を選択させることで行うことができる。この場合、配備指示部１６１は、デバイス情報記憶部１１０を参照して、デバイス管理テーブル１１１に登録されている配備先機器の名称のリストを画面に表示する。アプリ開発者は、全体アプリフローから配備先機器の指定対象とするノードを選択すると共に、そのノードに対応する機能の配備先となる配備先機器の名称を、配備先機器の名称のリストから選択する。すると配備指示部１６１は、選択されたノードに対応する機能の配備先が、選択された配備先機器であると認識する。
【００５７】
全体アプリフロー内のすべてのノードについて配備先機器が指定されると、配備指示部１６１は、全体アプリフローデータ記憶部１２０内の全体アプリフローデータ１２１を分配アプリ生成部１６３に送信する。さらに配備指示部１６１は、分配アプリ生成部１６３に対して、全体アプリフローデータ１２１に示される各ノードに対応する機能の配備先を指定する。その後、分配アプリ生成部１６３によって、配備先機器ごとの分配アプリフローデータが生成されると、配備指示部１６１は、分配アプリ配備部１６４に対して、分配アプリの配備先を指定して、分配アプリの配備を指示する。
【００５８】
全体アプリフロー編集部１６２は、アプリ開発者からの入力に従って、全体アプリフローを作成する。全体アプリフロー編集部１６２は、例えばＮｏｄｅ−ＲＥＤなどのフローベースのアプリ開発環境である。例えば全体アプリフロー編集部１６２は、Ｗｅｂブラウザ上での全体アプリフローの編集画面を表示し、アプリ開発者による入力に応じて、全体アプリフローの編集画面内で全体アプリフローを作成する。全体アプリフロー編集部１６２は、全体アプリフロー編集画面上での全体アプリフローを作成すると、全体アプリフローデータ１２１を生成する。そして全体アプリフロー編集部１６２は、生成した全体アプリフローデータ１２１を、例えば配備指示部１６１を介して全体アプリフローデータ記憶部１２０に格納する。
【００５９】
分配アプリ生成部１６３は、配備指示部１６１からの指示に従って、全体アプリフローデータ１２１に基づいて、ノードに対応する機能の配備先ごとの分配アプリを生成する。分配アプリ生成部１６３は、生成した分配アプリを分配アプリ配備部１６４に送信する。
【００６０】
分配アプリ配備部１６４は、配備指示部１６１からの指示に従って、分配アプリを、その分配アプリに対応する配備先機器に配備する。例えば分配アプリ配備部１６４は、分配アプリを示す分配アプリフローデータを配備先機器に送信し、配備先機器に対して分配アプリのインストールおよび起動を指示する。
【００６１】
機器経路情報登録部１７１は、アプリ開発サーバ１００の下位機器からの接続要求メッセージを受信する。そして機器経路情報登録部１７１は、接続要求メッセージに基づいて、ネットワークトポロジ７０における機器間の接続情報を機器接続情報記憶部１４０に格納する。
【００６２】
機器接続検知部１７２は、機器接続情報記憶部１４０を参照し、新たに配備先機器が接続されたことを検知する。機器接続検知部１７２は、新たな配備先機器を検知すると、配備アプリ判定部１７４に、新たに接続された配備先機器の機器名を含む機器接続検知情報を通知する。
【００６３】
障害状態判定部１７３は、下位機器からの障害発生通知メッセージを受信すると、配備先機器状態記憶部１５０に、配備先機器に障害が発生したことを示す情報を設定する。
配備アプリ判定部１７４は、配備先機器状態記憶部１５０を参照し、新たに接続された配備先機器で配備する分配アプリを判定する。例えば配備アプリ判定部１７４は、新たに接続された配備先機器が、障害が発生した配備先機器の代替機器の場合、障害が発生した配備先機器に配備済みの分配アプリを、新たに接続された配備先機器で配備する分配アプリと判定する。配備アプリ判定部１７４は、障害が発生した配備先機器に配備済みの分配アプリを示す情報を、配備済みアプリ再配備部１７５に通知する。
【００６４】
配備済みアプリ再配備部１７５は、障害が発生した配備先機器の配備済みの分配アプリを、その配備先機器の代替の配備先機器に再配備する。
なお、図５に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。また、図５に示した各要素の機能は、例えば、その要素に対応するプログラムモジュールをコンピュータに実行させることで実現することができる。
【００６５】
次に、アプリ開発サーバ１００内の各記憶部に格納されている情報について具体的に説明する。
図６は、デバイス情報記憶部の一例を示す図である。デバイス情報記憶部１１０には、デバイス管理テーブル１１１が格納されている。デバイス管理テーブル１１１には、例えば配備先機器の機器名に対応付けて、配備先機器のＩＰ（Internet Protocol）アドレス、サブネットマスク、および機器識別子が設定されている。サブネットマスクは、ＩＰアドレスのうちのネットワーク部の範囲を示す情報である。ＩＰアドレスとサブネットマスクとのビット単位の論理積により、ネットワーク部の値（ネットワークアドレス）が取得できる。ネットワークアドレスが共通の複数の配備先機器は、内部ネットワークで接続されているものと判断できる。機器識別子は、配備先機器を一意に識別する識別子である。機器識別子は、配備先機器間の通信路の識別子に用いることができる。例えば、データ送信元の配備先機器の機器識別子とデータ送信先の配備先機器の機器識別子とを組み合わせて通信識別子を作成することで、機器間の通信路を一意に識別する識別子を生成することができる。なお、ＩＰアドレスを配備先機器の機器識別子として用いてもよい。
【００６６】
なお、デバイス情報記憶部１１０内の情報は、例えばシステムの運用者によって予め登録されている。また、配備先機器がネットワークに接続された際に、その配備先機器が、アプリ開発サーバ１００へ、機器名、ＩＰアドレス、サブネットマスク、機器識別子を送信してもよい。この場合、アプリ開発サーバ１００は、配備先機器から送られた情報を、デバイス情報記憶部１１０に格納する。
【００６７】
図７は、全体アプリフローデータ記憶部の一例を示す図である。全体アプリフローデータ記憶部１２０には、全体アプリフローデータ１２１が格納されている。全体アプリフローデータ１２１は、全体アプリフロー編集部１６２により作成され、例えば配備指示部１６１により、全体アプリフローデータ記憶部１２０に格納される。全体アプリフローデータ１２１は、例えばＪＳＯＮ（JavaScript（登録商標） Object Notation）によって記述される。
【００６８】
全体アプリフローデータ１２１には、機能に対応するノードとノード間を接続する線で示された全体アプリフロー内のノードそれぞれを定義する記述（データ処理定義情報１２１ａ，１２１ｂ，１２１ｃ）が含まれている。データ処理定義情報１２１ａ，１２１ｂ，１２１ｃには、項目名「ｉｄ」の値としてそのノードの識別子が示されている。また、項目名「ｎａｍｅ」の値として、そのノードに対応する機能ブロックの名前が示されている。そして、出力側が他のノードに接続されたノードを定義するデータ処理定義情報には、項目名「ｗｉｒｅｓ」の値として、データ送信先のノードの識別子が示されている。
【００６９】
図８は、配備済みアプリ記憶部の一例を示す図である。配備済みアプリ記憶部１３０には、全体アプリフローデータ１２１に基づいて生成された複数の分配アプリフローデータ１３１，１３２，・・・が格納されている。分配アプリフローデータ１３１，１３２，・・・それぞれには、アプリ名が付与されている。例えば分配アプリフローデータ１３１のアプリ名は「ａｐｐ００１．ｊｓｏｎ」である。
【００７０】
分配アプリフローデータ１３１では、「日付データ生成」に対応するノードを定義するデータ処理定義情報１３１ａにおける項目名「ｗｉｒｅｓ」の値に示される送信先ノードの識別子が、「データ送信＿ＭＱＴＴ」に対応するノードの識別子に変更されている。また分配アプリフローデータ１３１には、「データ送信＿ＭＱＴＴ」に対応するノードを定義するデータ処理定義情報１３１ｂが追加されている。データ処理定義情報１３１ｂ内には、項目名「ｔｏｐｉｃ」の値として、ＭＱＴＴのトピックの値が設定されている。ＭＱＴＴのトピックは、ＭＱＴＴによる通信の通信識別子として用いられる。ＭＱＴＴのトピックの値は、例えば「日付データ生成」のノードの配備先である配備先機器の識別子「ｄｅｖ１」と、データ処理定義情報１２１ｂ（図７参照）内の「日付データ整形」のノードの配備先である配備先機器の識別子「ｄｅｖ２」とを含む値である。図８の例では、ＭＱＴＴのトピックとして値「ｄｅｖ１ｔｏｄｅｖ２」が設定されている。
【００７１】
図９は、機器接続情報記憶部の一例を示す図である。機器接続情報記憶部１４０には、例えば機器接続関係テーブル１４１が格納されている。機器接続関係テーブル１４１には、接続関係にある配備先機器の上流側の機器（上流機器）の機器名に対応付けて、その機器の下流側の機器（下流機器）の機器名が設定されている。
【００７２】
図１０は、配備先機器状態記憶部の一例を示す図である。配備先機器状態記憶部１５０には、例えば配備先機器状態テーブル１５１が格納されている。配備先機器状態テーブル１５１には、配備先機器の機器名に対応付けて、配備先機器に配備した分配アプリ（配備済みアプリ）のアプリ名と障害発生フラグとが設定されている。障害発生フラグは、対応する配備先機器の障害が検出されていなければ「０」が設定され、障害が検出されていれば「１」が設定される。
【００７３】
図１１は、配備先機器の機能の一例を示すブロック図である。配備先機器２００は、接続要求メッセージ送受信部２１０、下流機器情報記憶部２２０、キープアライブメッセージ送受信部２３０、応答メッセージ送受信部２４０、故障判定処理部２５０、および判定通知処理部２６０を有する。
【００７４】
接続要求メッセージ送受信部２１０は、接続要求メッセージの送受信を行う。例えば接続要求メッセージ送受信部２１０は、下流機器２００ｂから接続要求メッセージを受信し、自身の下流機器を認識する。接続要求メッセージ送受信部２１０は、接続要求メッセージの送信元である下流機器２００ｂの装置名を、下流機器情報記憶部２２０に格納する。また接続要求メッセージ送受信部２１０は、下流機器２００ｂから受信した接続要求メッセージを上流機器２００ａに転送する。その際、接続要求メッセージ送受信部２１０は、接続要求メッセージに、転送経路を示す情報として配備先機器２００自身の装置名を付与する。
【００７５】
また接続要求メッセージ送受信部２１０は、配備先機器２００が新たにシステムに追加された場合、接続要求メッセージを生成し、その接続要求メッセージを上流機器２００ａに送信する。なお論理トポロジにおける上流機器２００ａがどの機器なのか（例えば機器名とＩＰアドレス）は、配備先機器２００のシステムへの追加時に、予め接続要求メッセージ送受信部２１０に設定される。
【００７６】
下流機器情報記憶部２２０は、配備先機器２００の下流機器の情報を記憶する。例えば配備先機器２００のメモリまたはストレージ装置の記憶領域の一部が、下流機器情報記憶部２２０として使用される。
【００７７】
キープアライブメッセージ送受信部２３０は、キープアライブメッセージの送受信を行う。例えばキープアライブメッセージ送受信部２３０は、定期的に下流機器２００ｂに対してキープアライブメッセージを送信する。このとき、キープアライブメッセージ送受信部２３０は、キープアライブメッセージを送信したことを、応答メッセージ送受信部２４０に通知する。またキープアライブメッセージ送受信部２３０は、上流機器２００ａが送信したキープアライブメッセージを受信する。そしてキープアライブメッセージ送受信部２３０は、キープアライブメッセージを受信したことを、応答メッセージ送受信部２４０に通知する。
【００７８】
応答メッセージ送受信部２４０は、下流機器２００ｂからの、キープアライブメッセージへの応答メッセージを受信する。応答メッセージ送受信部２４０は、下流機器２００ｂから応答メッセージを受信すると、応答メッセージを受信したことを故障判定処理部２５０に通知する。また応答メッセージ送受信部２４０は、キープアライブメッセージを受信した旨の通知をキープアライブメッセージ送受信部２３０から取得すると、応答メッセージを上流機器２００ａに送信する。
【００７９】
故障判定処理部２５０は、下流機器２００ｂに送信したキープアライブメッセージに対する応答メッセージの受信状況に基づいて、下流機器２００ｂの故障の有無を判定する。例えば故障判定処理部２５０は、キープアライブメッセージを送信してから所定時間以内に応答メッセージを受信できなければ、下流機器２００ｂが故障していると判定する。故障判定処理部２５０は、判定結果を判定通知処理部２６０に通知する。
【００８０】
判定通知処理部２６０は、故障判定処理部２５０から受信した判定結果を、上流機器２００ａに送信する。例えば判定通知処理部２６０は、下流機器２００ｂが正常に動作していると判定した場合、上流機器２００ａに対して、障害非発生通知メッセージを送信する。また判定通知処理部２６０は、下流機器２００ｂが正常に動作していないと判定した場合、上流機器２００ａに対して、障害発生通知メッセージを送信する。
【００８１】
なお、図１１に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。また、図１１に示した各要素の機能は、例えば、その要素に対応するプログラムモジュールをコンピュータに実行させることで実現することができる。
【００８２】
次に、下流機器情報記憶部２２０に格納される情報について、具体的に説明する。
図１２は、下流機器情報記憶部の一例を示す図である。例えば下流機器情報記憶部２２０には、下流機器情報テーブル２２１が格納される。下流機器情報テーブル２２１には、配備先機器２００の下流機器の機器名に対応付けて、下流機器と通信するためのアドレスが設定されている。アドレスは、例えばＩＰアドレスである。図１２の例では、配備先機器２００が、ネットワークトポロジ７０における配備先機器７３である場合における、下流機器の機器名とアドレスとの組が、下流機器情報テーブル２２１に設定されている。
【００８３】
以上のような機能を有するマスタであるアプリ開発サーバ１００と配備先機器とが連係動作することで、分配アプリの配備と、分配アプリを配備した配備先機器が故障した場合の代替の配備先機器への分配アプリの自動配備とが実現される。アプリ開発サーバ１００と配備先機器とが連係動作して実現する処理は、大別して分配アプリ生成・配備フェーズ、システム構築フェーズ、および運用フェーズに分かれる。以下フェーズごとの処理を詳細に説明する。
【００８４】
＜分配アプリ生成・配備フェーズ＞
まず、分配アプリ生成・配備フェーズについて説明する。分配アプリ生成・配備フェーズでは、アプリ開発サーバ１００が全体アプリフローに基づいて分配アプリを自動生成し、生成した分配アプリを配備先機器に配備する。
【００８５】
図１３は、分配アプリの自動生成および配備処理の一例を示す図である。全体アプリフロー編集部１６２は、アプリ開発者の入力に基づいて、全体アプリフロー８１を作成する。全体アプリフロー８１に含まれる各ノード８１ａ〜８１ｄは、アプリ開発者によって、対応する機能の配備先が指定されている。例えばノード８１ａ，８１ｂに対応する機能（センサデバイス制御、センサ入力値加工）の配備先は「機器Ａ」である。ノード８１ｃに対応する機能（フィルタリング）の配備先は「機器Ｂ」である。ノード８１ｄに対応する機能（可視化）の配備先は「機器Ｃ」である。この全体アプリフロー８１は、例えばセンサから取得したデータを入力データとして、特定デバイス固有のデータ取得処理、取得したデータの加工処理、データのフィルタリング処理（例えば平均化処理など）、取得データの可視化などを順に行うことを示す。
【００８６】
アプリ開発者から分配アプリの生成指示が入力されると、全体アプリフロー編集部１６２が作成した全体アプリフロー８１を定義する全体アプリフローデータ１２１が、配備指示部１６１により全体アプリフローデータ記憶部１２０から読み出される。そして配備指示部１６１から分配アプリ生成部１６３へ全体アプリフローデータ１２１が送信される。すると分配アプリ生成部１６３は、全体アプリフローデータ１２１に基づいて、分配アプリ８２〜８４を生成する。
【００８７】
例えば分配アプリ生成部１６３は、まず全体アプリフロー８１内のノードを、配備先機器ごとに分割する。図１３の例では、配備先が「機器Ａ」のノード８１ａ，８１ｂと、配備先が「機器Ｂ」のノード８１ｃと、配備先が「機器Ｃ」のノード８１ｄとに分割される。
【００８８】
さらに分配アプリ生成部１６３は、全体アプリフロー８１の分割部分のリンク（全体アプリフロー８１における接続線）を通信処理ノードに置き換える。具体的には、分配アプリ生成部１６３は、データ送信元のノードの出力側（図中右側）にデータ送信処理のノードを追加し、データ送信先のノードの入力側（図中左側）にデータ受信処理のノードを追加する。図１３の例では、ノード８１ｂの出力側に、データ送信処理のノード８１ｅが追加されている。またノード８１ｃの入力側に、データ受信処理のノード８１ｆが追加され、ノード８１ｃの出力側に、データ送信処理のノード８１ｇが追加されている。さらにノード８１ｄの入力側に、データ受信処理のノード８１ｈが追加されている。追加されたデータ送信処理のノード８１ｅ，８１ｇには、例えばデータ送信先の機器との通信を一意に示す識別子が付与される。また追加されたデータ受信処理のノード８１ｆ，８１ｈには、例えばデータ送信元の機器との通信を一意に示す識別子が付与される。
【００８９】
なお、既存のノードの出力側にノードを追加するとは、分配アプリフローにおいて、追加するノードをアプリフローに追加すると共に、既存のノードの出力側と追加するノードの入力側とを通信のリンクを示す線で接続することである。また既存のノードの入力側にノードを追加するとは、分配アプリフローにおいて、追加するノードをアプリフローに追加すると共に、既存のノードの入力側と追加するノードの出力側とを通信のリンクを示す線で接続することである。
【００９０】
このようにして、配備先機器ごとの分配アプリ８２〜８４が生成される。生成された分配アプリ８２〜８４は、それぞれ指定された配備先機器に配備される。具体的には、「機器Ａ」用の分配アプリ８２は「機器Ａ」に配備され、「機器Ｂ」用の分配アプリ８３は「機器Ｂ」に配備され、「機器Ｃ」用の分配アプリ８４は「機器Ｃ」に配備される。
【００９１】
なお分配アプリ生成部１６３は、データ送信用またはデータ受信用のノードを追加する際、データ送信側とデータ受信側とで共通の通信プロトコルにより通信を行うノードを追加する。例えば分配アプリ生成部１６３は、通信に高いセキュリティが求められる場合には、通信プロトコルを、高いセキュリティ機能を有するプロトコルに決定する。すなわち、インターネットのような広域ネットワーク２０ｂを経由した通信の場合、データが第３者に漏洩する危険がある。このような場合、分配アプリ生成部１６３は、送信されるデータが第３者に漏洩しないように、ＨＴＴＰのような高いセキュリティ機能を有するプロトコルで通信するためのデータ送信およびデータ受信のノードを追加する。ＨＴＴＰは、例えばＨＴＴＰＳのような認証や暗号化技術を用いた通信が可能なプロトコルである。
【００９２】
また分配アプリ生成部１６３は、高い処理効率が求められる場合には、通信プロトコルを、効率的な通信が可能なプロトコルに決定する。例えば、企業内のローカルネットワーク２０ａのようなプライベートのネットワークを経由して、大量の機器からデータを収集する場合、個々のデータ通信のための処理負荷が高いと、収集する機器における負荷、およびネットワーク上の通信負荷が過大となる。このような場合、分配アプリ生成部１６３は、ＭＱＴＴのような効率的なデータ通信が可能なプロトコルで通信するためのデータ送信およびデータ受信のノードを追加する。ＭＱＴＴは、ＨＴＴＰに比べてヘッダサイズが非常に小さく、通信量や送受信する機器の負荷を低く抑えることができるプロトコルである。
【００９３】
次に、分配アプリの生成および配備の手順について詳細に説明する。
図１４は、分配アプリの生成および配備手順を示すフローチャートである。以下、図１４に示す処理をステップ番号に沿って説明する。
【００９４】
［ステップＳ１０１］全体アプリフロー編集部１６２は、アプリ開発者からの入力に基づいて、ＩｏＴアプリとして実行するデータ処理を定義する全体アプリフローを作成する。
【００９５】
［ステップＳ１０２］配備指示部１６１は、アプリ開発者からの、全体アプリフローで定義したノードに対して、実際のＩｏＴシステム上のどの機器でその処理を行うか（配備先機器）の指定を受け付ける。例えば配備指示部１６１は、デバイス管理テーブル１１１に登録されている機器名を、配備先機器の候補としてモニタ２１に表示する。アプリ開発者は、ノードごとに、そのノードに対応する機能を実行させる配備先機器を、候補として表示された機器名の中から選択する。配備指示部１６１は、ノードごとに選択された機器名を、そのノードの配備先機器の機器名としてメモリ１０２に格納する。
【００９６】
［ステップＳ１０３］配備指示部１６１は、アプリ開発者からの、分配アプリの配備指示を受け付ける。配備の指示とは、全体アプリを指定した配備先機器ごとに分離し、適切な機能を追加して分配アプリを生成し、分配アプリを対応する配備先機器に転送する処理を指示するものである。配備指示部１６１は、配備指示が入力されると、全体アプリフローを表す全体アプリフローデータと、全体アプリフローデータ内の各ノードの配備先情報を分配アプリ生成部１６３に送信する。
【００９７】
［ステップＳ１０４］分配アプリ生成部１６３は、全体アプリフローと配備先情報とに基づいて、分配アプリを生成する。分配アプリ生成部１６３は、生成した分配アプリを示す分配アプリフローデータを、分配アプリ配備部１６４に送信する。なお分配アプリ生成処理の詳細は後述する（図１５参照）。
【００９８】
［ステップＳ１０５］分配アプリ配備部１６４は、分配アプリを、その分配アプリの配備先機器に配備する。具体的には、分配アプリ配備部１６４は、配備先機器ごとの分配アプリの分配アプリフローデータを、その分配アプリに対応する配備先機器に対して送信する。さらに分配アプリ配備部１６４は、送信した分配アプリフローデータによる分配アプリのインストールおよび起動要求を、配備先機器に送信する。これにより、配備先機器は、分配アプリフローデータに定義された処理が実行できるように、インストール作業を行い、分配アプリを起動する。
【００９９】
なお配備先機器が、分配アプリフローデータをインポートするＡＰＩ（Application Programming Interface）を備えている場合がある。この場合、分配アプリ配備部１６４は、例えば配備先機器の分配アプリフロー登録用のＡＰＩに対してデータを送付する。これにより、配備先機器内の分配アプリフローデータの実行ソフトウェアに分配アプリフローデータが実行対象として設定される。このように、分配アプリフロー登録用のＡＰＩを用いて分配アプリを配備することも可能である。
【０１００】
分配アプリ配備部１６４による分配アプリの配備は、分配アプリ生成処理での分配アプリ生成から連続して行ってもよいし、あるいは分配アプリ生成後にさらにアプリ開発者からの任意のタイミングの指示に応じて行ってもよい。
【０１０１】
次に、分配アプリ生成処理について詳細に説明する。
図１５は、分配アプリ生成処理の手順の一例を示すフローチャートである。以下、図１５に示す処理をステップ番号に沿って説明する。
【０１０２】
［ステップＳ１１１］分配アプリ生成部１６３は、全体アプリフローからノードを１つ選択する。
［ステップＳ１１２］分配アプリ生成部１６３は、ステップＳ１０２において受け付けた配備先機器の指定に基づいて、選択したノード（選択ノード）の出力データの転送先となるノード（転送先ノード）の配備先機器が、選択ノードの配備先機器と同じか否かを判断する。配備先機器が同じであれば、処理をステップＳ１２５に進める。配備先機器が異なれば、処理をステップＳ１１３に進める。
【０１０３】
［ステップＳ１１３］分配アプリ生成部１６３は、選択ノードと転送先ノードとの間で、選択ノードを含むアプリフローを分離する。例えば分配アプリ生成部１６３は、選択ノードを含むアプリフローを、選択ノードを最後尾とするアプリフローと、転送先ノードを先頭とするアプリフローとに分離する。分離により生成されたアプリフローが、分配アプリフローとなる。なお、分配アプリフローがさらに分離される場合もある。アプリフローが分離されることで、分離後の分配アプリフローを示すアプリフローデータ（分配アプリフローデータ）が生成される。
【０１０４】
分配アプリ生成部１６３は、以下のステップＳ１１４〜ステップＳ１２４の処理により、分配アプリフローを自動編集する。分配アプリ生成部１６３の編集処理は、具体的には、メモリ１０２内で分配アプリフローデータを編集する処理である。
【０１０５】
［ステップＳ１１４］分配アプリ生成部１６３は、転送先ノードが、外部のネットワークを介して接続されているか否かを判断する。例えば分配アプリ生成部１６３は、選択したノードと転送先ノードとのＩＰアドレス内のネットワーク部のアドレスが異なる場合、外部のネットワークを介して接続されていると判断する。分配アプリ生成部１６３は、外部のネットワークを介して接続されている場合、処理をステップＳ１１５に進める。また分配アプリ生成部１６３は、内部のネットワークを介して接続されている場合、処理をステップＳ１２０に進める。
【０１０６】
［ステップＳ１１５］分配アプリ生成部１６３は、選択ノードの出力側にＨＴＴＰ送信処理ノードを追加する。追加されるＨＴＴＰ送信処理ノードは、例えば外部ネットワークへの接続のために設置されたＨＴＴＰプロキシサーバを通過するための処理が記述された機能ブロックに対応するノードである。さらに、分配アプリ生成部１６３は、ＨＴＴＰ送信処理ノードの出力側に、転送先ノードからの応答を処理するための応答ノードを追加する。
【０１０７】
［ステップＳ１１６］分配アプリ生成部１６３は、転送先ノードの入力側にＨＴＴＰ受信処理ノードを追加する。さらに、分配アプリ生成部１６３は、ＨＴＴＰ受信処理ノードの出力側に、選択ノードへのＨＴＴＰ受信応答を行うための応答ノードを追加する。
【０１０８】
［ステップＳ１１７］分配アプリ生成部１６３は、選択ノードの転送先を、追加したＨＴＴＰ送信処理ノードに変更する。例えば分配アプリ生成部１６３は、選択ノードの転送先を示す情報を、ＨＴＴＰ送信処理ノードのノードＩＤに変更する。
【０１０９】
［ステップＳ１１８］分配アプリ生成部１６３は、追加したＨＴＴＰ受信処理ノードの転送先情報に、転送先ノードのノードＩＤを付与する。
［ステップＳ１１９］分配アプリ生成部１６３は、追加したＨＴＴＰ送信処理ノードに、転送先ノードの配備先機器のＩＰアドレスを設定する。その後、分配アプリ生成部１６３は、処理をステップＳ１２５に進める。
【０１１０】
［ステップＳ１２０］分配アプリ生成部１６３は、選択ノードの出力側に、ＭＱＴＴ送信処理ノードを追加する。
［ステップＳ１２１］分配アプリ生成部１６３は、転送先ノードの入力側に、ＭＱＴＴ受信処理ノードを追加する。
【０１１１】
［ステップＳ１２２］分配アプリ生成部１６３は、選択ノードの転送先を、追加したＭＱＴＴ送信処理ノードに変更する。例えば分配アプリ生成部１６３は、選択ノードの転送先を示す情報を、ＭＱＴＴ送信処理ノードのノードＩＤに変更する。
【０１１２】
［ステップＳ１２３］分配アプリ生成部１６３は、追加したＭＱＴＴ受信処理ノードの転送先情報に、転送先ノードのノードＩＤを付与する。
［ステップＳ１２４］分配アプリ生成部１６３は、追加したＭＱＴＴ送信処理ノードと追加したＭＱＴＴ受信処理ノードとのそれぞれに、ＭＱＴＴ送信処理ノードとＭＱＴＴ受信処理ノードとの組を一意に示す通信識別子（トピック）を設定する。
【０１１３】
［ステップＳ１２５］分配アプリ生成部１６３は、全体アプリフロー内のすべてのノードを選択したか否かを判断する。分配アプリ生成部１６３は、すべてのノードが選択済みであれば、分配アプリ生成処理を終了する。分配アプリ生成部１６３は、未選択のノードが存在すれば、処理をステップＳ１１１に進める。
【０１１４】
このようにして、全体アプリを、指定された配備先機器が共通のノードごとに分割し、分散環境上での分配アプリの連携のための配備先機器間の通信処理機能を、分配アプリフロー上の適切な位置に自動的に付加することができる。しかも、配備先機器間の通信が、外部ネットワークを経由するのか否かにより、適切な通信プロトコルを適用することができる。
【０１１５】
アプリ開発サーバ１００は、生成した分配アプリを、複数の配備先機器に配備する。その後、配備先機器の一部で障害が発生すると、その配備先機器に配備した分配アプリが正常に機能しなくなる。その場合、システムの管理者によって、障害が発生した配備先機器の代替となる配備先機器が、ネットワークに接続される。すると、配備先機器とアプリ開発サーバ１００との連係によるシステム構築フェーズが実施される。
【０１１６】
＜システム構築フェーズ＞
次に、システム構築フェーズについて説明する。システム構築フェーズは、システム内に新たな配備先機器が接続されるごとに、アプリ開発サーバ１００が有する機器接続情報を更新する処理である。
【０１１７】
図１６は、システム構築フェーズにおける機器接続情報の更新例を示す図である。例えば配備先機器７５の下流側に配備先機器７８が新たに接続された場合を想定する。配備先機器７８には、例えば予め上位機器となる配備先機器７５のＩＰアドレスが設定されている。配備先機器７８は、ネットワーク２０に接続されると、接続要求メッセージ９１を上位機器に送信する。接続要求メッセージ９１には、要求元として、配備先機器７８の装置名「Ｇ」が設定されている。
【０１１８】
接続要求メッセージ９１を受信した配備先機器７５は、接続要求メッセージ９１に示される要求元の機器名「Ｇ」と要求元のＩＰアドレスとを、下流機器情報として格納する。さらに配備先機器７５は、配備先機器７５の上位機器である配備先機器７２に接続要求メッセージ９２を転送する。その際、配備先機器７５は、転送する接続要求メッセージ９２の経路の情報に、自身の装置名「Ｄ」を追加する。
【０１１９】
接続要求メッセージ９２を受信した配備先機器７２は、配備先機器７２の上位機器であるマスタ７１に接続要求メッセージ９３を転送する。その際、配備先機器７２は、転送する接続要求メッセージ９３の経路の情報に、自身の装置名「Ａ」を、すでに設定されている機器名「Ｄ」の後に追加する。
【０１２０】
接続要求メッセージ９３を受信したマスタ７１は、接続要求メッセージ９３の要求元の機器名「Ｇ」に基づいて、機器名「Ｇ」の配備先機器７８が接続されたことを認識する。またマスタ７１は、接続要求メッセージ９３の経路の情報に示される機器名の並びに基づいて、接続要求メッセージ９３が機器名「Ｇ」の配備先機器７５、機器名「Ａ」の配備先機器７２を介して転送されたことを認識する。そしてマスタ７１は、新たに接続された配備先機器７８のネットワークトポロジ７０上の接続先機器が、配備先機器７５であると判断する。マスタ７１は、機器接続情報記憶部１４０内の機器接続関係テーブル１４１の上流機器として、接続先機器の機器名「Ｄ」が未登録の場合、上流機器「Ｄ」のレコードを、機器接続関係テーブル１４１に追加する。そしてマスタ７１は、上流機器「Ｄ」のレコードの下位機器に、新たに接続された配備先機器７８の機器名「Ｇ」を登録する。
【０１２１】
このようにして、機器接続関係テーブル１４１を常に最新の状態に保つことができる。すなわちマスタ７１であるアプリ開発サーバ１００では、システム内に新たな配備先機器が追加されると、その機器の機器名と、その機器の上流機器とをすぐに認識できる。
【０１２２】
次に、システム構築フェーズの処理を実現するために配備先機器２００と、マスタ７１であるアプリ開発サーバ１００とが実行する処理について詳細に説明する。配備先機器２００が実行する処理には、配備先機器２００がネットワーク２０に新たに接続されたときの接続要求メッセージ送信処理と、下流機器から接続要求メッセージを受信したときの接続要求メッセージ転送処理とがある。
【０１２３】
図１７は、新規に接続された配備先機器による接続要求メッセージ送信処理の手順の一例を示すフローチャートである。以下、図１７に示す処理をステップ番号に沿って説明する。
【０１２４】
［ステップＳ２０１］接続要求メッセージ送受信部２１０は、配備先機器２００がネットワーク２０に接続されたか否かを判断する。例えば接続要求メッセージ送受信部２１０は、配備先機器２００のＯＳが起動され、ＴＣＰ（Transmission Control Protocol）／ＩＰによる他の機器との通信が可能な状態になったとき、ネットワーク２０に接続されたと判断する。接続要求メッセージ送受信部２１０は、ネットワーク２０に接続された場合、処理をステップＳ２０２に進める。また接続要求メッセージ送受信部２１０は、ネットワーク２０に接続されていなければ、ステップＳ２０１の処理を繰り返す。
【０１２５】
［ステップＳ２０２］接続要求メッセージ送受信部２１０は、自身の機器名を含む接続要求メッセージを生成し、予め指定されたＩＰアドレスの上位機器に、生成した接続要求メッセージを送信する。
【０１２６】
次に配備先機器２００が、下位機器から接続要求メッセージを受信した場合の接続要求メッセージの転送処理について説明する。
図１８は、配備先機器による接続要求メッセージ転送処理の手順の一例を示すフローチャートである。以下、図１８に示す処理をステップ番号に沿って説明する。
【０１２７】
［ステップＳ２１１］接続要求メッセージ送受信部２１０は、下位機器から送信された接続要求メッセージを受信する。
［ステップＳ２１２］接続要求メッセージ送受信部２１０は、接続要求メッセージの送信元が自身の下流側に隣接する下流機器の場合、接続要求メッセージに示される要求元機器情報を、下流機器情報テーブル２２１に設定する。要求元機器情報は、例えば要求元の機器名と送信元のＩＰアドレスである。なお接続要求メッセージ送受信部２１０は、接続要求メッセージの送信元が自身の下流側に隣接する下流機器かどうかは、接続要求メッセージの経路の情報に基づいて判断することができる。例えば接続要求メッセージ送受信部２１０は、接続要求メッセージの経路の情報に他の配備先機器の機器名が登録されていなければ、接続要求メッセージの送信元が自身の下流側に隣接する下流機器であると判断する。
【０１２８】
［ステップＳ２１３］接続要求メッセージ送受信部２１０は、接続要求メッセージの経路の情報に、自機器情報を付与する。例えば接続要求メッセージ送受信部２１０は、経路の情報の最後尾に、自身の機器名を追加する。
【０１２９】
［ステップＳ２１４］接続要求メッセージ送受信部２１０は、自機器の接続先機器に接続要求メッセージを転送する。
このような接続要求メッセージの転送を各配備先機器が実施することで、最終的にマスタ７１であるアプリ開発サーバ１００に接続要求メッセージが転送される。そしてアプリ開発サーバ１００が、接続機器登録を行う。
【０１３０】
図１９は、マスタによる接続機器登録処理の手順の一例を示すフローチャートである。以下、図１９に示す処理をステップ番号に沿って説明する。
［ステップＳ２２１］機器経路情報登録部１７１は、いずれかの配備先機器から接続要求メッセージを受信する。
【０１３１】
［ステップＳ２２２］機器経路情報登録部１７１は、機器接続関係テーブル１４１を参照し、接続要求メッセージの送信元の接続先である配備先機器の機器名が、上流機器として設定されたレコードがあるか否かを判断する。機器経路情報登録部１７１は、該当レコードがある場合、処理をステップＳ２２３に進める。また機器経路情報登録部１７１は、該当レコードがない場合、処理をステップＳ２２４に進める。
【０１３２】
［ステップＳ２２３］機器経路情報登録部１７１は、接続要求メッセージの経路の情報に示される接続先機器の機器名を上流機器とし、接続要求メッセージの要求元機器の機器名を下流機器とする新たなレコードを、機器接続関係テーブル１４１に登録する。機器経路情報登録部１７１は、その後、処理をステップＳ２２５に進める。
【０１３３】
［ステップＳ２２４］機器経路情報登録部１７１は、機器接続関係テーブル１４１内の、配備先機器の機器名が上流機器に設定されている登録済みのレコードの下流機器として、要求元機器の機器名を登録する。
【０１３４】
［ステップＳ２２５］機器接続検知部１７２は、新たな配備先機器の接続を検知し、要求元機器の機器名を含む機器接続検知情報を配備アプリ判定部１７４に通知する。
このようにして、ネットワーク２０に新たな配備先機器が接続されたことが検知され、機器接続検知情報が配備アプリ判定部１７４に通知される。このようなシステム構築フェーズと並行して、配備先機器とアプリ開発サーバ１００とにより運用フェーズが実行される。
【０１３５】
＜運用フェーズ＞
次に運用フェーズについて説明する。運用フェーズでは、障害が発生した配備先機器の検知と、その配備先機器に配備済みの分配アプリの再配備とが行われる。
【０１３６】
図２０は、配備先機器の障害検知例を示す図である。図２０の例では、配備先機器７６に障害が発生したものとする。配備先機器７６の状態は、配備先機器７６の上流機器である配備先機器７３が監視する。例えば配備先機器７３は、定期的にキープアライブメッセージ９４を配備先機器７６に送信する。配備先機器７６が正常に動作している場合、配備先機器７６は、キープアライブメッセージ９４に対して応答メッセージを返信する。他方、配備先機器７６に障害が発生した場合、配備先機器７６は、キープアライブメッセージ９４に対する応答メッセージを送信することができない。上流機器である配備先機器７３は、キープアライブメッセージ９４に対して応答メッセージが返されないことを検知すると、配備先機器７６に障害が発生したと判断する。
【０１３７】
配備先機器７３は、配備先機器７６に障害が発生したことを検知した場合、配備先機器７６の機器名を含む障害発生通知メッセージ９５をマスタ７１宛てに送信する。マスタ７１であるアプリ開発サーバ１００は、障害発生通知メッセージ９５に基づいて、配備先機器７６で障害が発生したことを認識する。
【０１３８】
図２１は、上流機器による下流機器状態確認処理の手順の一例を示すフローチャートである。以下、図２１に示す処理をステップ番号に沿って説明する。
［ステップＳ３０１］キープアライブメッセージ送受信部２３０は、下流機器に対してキープアライブメッセージを送信する。例えばキープアライブメッセージ送受信部２３０は、下流機器情報記憶部２２０を参照し、自身の下流機器のＩＰアドレスを取得する。そしてキープアライブメッセージ送受信部２３０は、取得したＩＰアドレス宛てのキープアライブメッセージを生成し、下流機器に対して生成したキープアライブメッセージを送信する。キープアライブメッセージ送受信部２３０は、キープアライブメッセージを送信したことを示す情報を、故障判定処理部２５０に通知する。
【０１３９】
［ステップＳ３０２］故障判定処理部２５０は、キープアライブメッセージが送信されると、キープアライブメッセージの応答メッセージ待ち時間計測用のタイマをスタートさせる。
【０１４０】
［ステップＳ３０３］故障判定処理部２５０は、タイマをスタートしてからの経過時間が、応答メッセージ待ち時間の上限である受信上限時間を超過したか否かを判断する。故障判定処理部２５０は、タイマの時間が受信上限時間を超過した場合、処理をステップＳ３０４に進める。また故障判定処理部２５０は、タイマの時間が受信上限時間を超過していなければ、処理をステップＳ３０６に進める。
【０１４１】
［ステップＳ３０４］故障判定処理部２５０は、キープアライブメッセージの送信先の下流機器が障害発生状態であると判断する。
［ステップＳ３０５］故障判定処理部２５０は、上流機器に対して、障害発生通知メッセージを送信する。その後、故障判定処理部２５０は、下流機器状態確認処理を終了する。
【０１４２】
［ステップＳ３０６］故障判定処理部２５０は、応答メッセージを受信したか否かを判断する。例えば下流機器から応答メッセージが送信されると、その応答メッセージを応答メッセージ送受信部２４０が受信する。応答メッセージ送受信部２４０は、応答メッセージを受信すると、応答メッセージを受信したことを示す情報を、故障判定処理部２５０に通知する。故障判定処理部２５０は、応答メッセージ送受信部２４０からの通知により、応答メッセージの受信を認識する。故障判定処理部２５０は、応答メッセージを受信したと判断した場合、処理をステップＳ３０７に進める。また故障判定処理部２５０は、応答メッセージを受信していなければ、処理をステップＳ３０３に進める。
【０１４３】
［ステップＳ３０７］故障判定処理部２５０は、タイマを停止する。
［ステップＳ３０８］故障判定処理部２５０は、上流機器に対して、障害非発生通知メッセージを送信する。
【０１４４】
配備先機器２００の下流機器が複数ある場合、図２１に示した処理が下流機器ごとに実行される。配備先機器２００から送信された障害発生通知メッセージまたは障害非発生通知メッセージは、上流側の配備先機器により、上流側に向かって転送され、最終的にマスタ７１であるアプリ開発サーバ１００に送られる。
【０１４５】
下流側の配備先機器では、キープアライブメッセージに応じた状態通知処理が行われる。
図２２は、下流機器における状態通知処理の手順の一例を示すフローチャートである。以下、図２２に示す処理をステップ番号に沿って説明する。
【０１４６】
［ステップＳ３１１］キープアライブメッセージ送受信部２３０は、上流機器からのキープアライブメッセージを受信したか否かを判断する。キープアライブメッセージ送受信部２３０は、キープアライブメッセージを受信していれば、処理をステップＳ３１２に進める。またキープアライブメッセージ送受信部２３０は、キープアライブメッセージを受信していなければ、ステップＳ３１１の処理を繰り返す。
【０１４７】
［ステップＳ３１２］キープアライブメッセージ送受信部２３０は、キープアライブメッセージを受信したことを示す情報を、応答メッセージ送受信部２４０に通知する。すると、応答メッセージ送受信部２４０は、上流機器に対して応答メッセージを送信する。
【０１４８】
図２１、図２２に示した処理を各配備先機器が行うことにより、アプリ開発サーバ１００には、各配備先機器についての障害発生通知メッセージまたは障害非発生通知メッセージを定期的に受信する。アプリ開発サーバ１００は、障害発生通知メッセージまたは障害非発生通知メッセージに基づいて、障害が発生した配備先機器の存在を認識する。
【０１４９】
図２３は、マスタにおける障害状態判定処理の手順の一例を示すフローチャートである。以下、図２３に示す処理をステップ番号に沿って説明する。
［ステップＳ３２１］障害状態判定部１７３は、下流機器から障害発生状態の通知メッセージ（障害発生通知メッセージまたは障害非発生通知メッセージ）を受信したか否かを判断する。障害状態判定部１７３は、障害発生状態の通知メッセージを受信した場合、処理をステップＳ３２２に進める。また障害状態判定部１７３は、障害発生状態の通知メッセージを受信していなければ、ステップＳ３２１の処理を繰り返す。
【０１５０】
［ステップＳ３２２］障害状態判定部１７３は、受信したメッセージに基づいて、障害が発生したか否かを判断する。例えば障害状態判定部１７３は、障害発生通知メッセージを受信した場合、障害が発生したと判断する。また障害状態判定部１７３は、障害非発生通知メッセージを受信した場合、障害が発生していないと判断する。障害状態判定部１７３は、障害が発生した場合、処理をステップＳ３２３に進める。また障害状態判定部１７３は、障害が発生していなければ、処理をステップＳ３２４に進める。
【０１５１】
［ステップＳ３２３］障害状態判定部１７３は、配備先機器状態テーブル１５１に対して、障害非発生通知メッセージに示される配備先機器の障害発生フラグに「１」を設定する。その後、障害状態判定部１７３は障害状態判定処理を終了する。
【０１５２】
［ステップＳ３２４］障害状態判定部１７３は、配備先機器状態テーブル１５１に対して、障害非発生通知メッセージに示される配備先機器の障害発生フラグに「０」を設定する。
【０１５３】
このようにして、各配備先機器の障害の有無が配備先機器状態テーブル１５１に反映される。障害が発生した配備先機器の代替の配備先機器が新たに接続された際には、配備先機器状態テーブル１５１に基づいて、配備アプリ判定部１７４により、代替の配備先機器に配備する分配アプリが判断される。そして配備済みアプリ再配備部１７５により、代替の配備先機器への分配アプリの配備が行われる。
【０１５４】
図２４は、アプリ再配備例を示す図である。図２４では、配備先機器７６に障害が発生し、配備先機器７６の代替として配備先機器７９が接続された場合を想定している。マスタ７１であるアプリ開発サーバ１００は、配備先機器７９が接続されたことを検知すると、配備先機器７９と同じ上流機器に接続されている他の配備先機器を検索する。図２４の例では、配備先機器７９の上流機器は、配備先機器７３である。この配備先機器７３の下流機器としては、配備先機器７９以外に、配備先機器７６と配備先機器７７とが存在する。アプリ開発サーバ１００は、配備先機器７６と配備先機器７７との状態を確認し、配備先機器７６に障害が発生していることを認識する。そしてアプリ開発サーバ１００は、新たに接続された配備先機器７９は、配備先機器７６の代替機器であると判断する。
【０１５５】
配備先機器７６には、アプリ名「ａｐｐ００２」の分配アプリが配備済みである。そこでアプリ開発サーバ１００は、新たに接続された配備先機器７９に、アプリ名「ａｐｐ００２」の分配アプリを配備する。
【０１５６】
図２５は、アプリ再配備処理の手順の一例を示すフローチャートである。以下、図２５に示す処理をステップ番号に沿って説明する。
［ステップＳ３３１］配備アプリ判定部１７４は、配備先機器の動作状態を監視する。例えば配備アプリ判定部１７４は、配備先機器状態テーブル１５１の障害発生フラグの値により、各配備先機器の障害の有無を判断する。
【０１５７】
［ステップＳ３３２］配備アプリ判定部１７４は、機器接続検知部１７２から、新たに接続された配備先機器の機器名を含む機器接続通知を受信する。
［ステップＳ３３３］配備アプリ判定部１７４は、機器接続関係テーブル１４１から、新たに接続された配備先機器（接続機器）と同じ上流機器に接続された他の下流機器を検索する。例えば配備アプリ判定部１７４は、接続機器の機器名を下流機器として含むレコードを、機器接続関係テーブル１４１から検索する。そして配備アプリ判定部１７４は、該当するレコードに示されている下流機器の機器名のうち、接続機器以外の機器名を取得する。
【０１５８】
［ステップＳ３３４］配備アプリ判定部１７４は、接続機器以外の下流機器があるか否かを判断する。配備アプリ判定部１７４は、ステップＳ３３３の処理により、少なくとも１つの機器名が取得できた場合、接続機器以外の下流機器があると判断する。配備アプリ判定部１７４は、接続機器以外の下流機器がある場合、処理をステップＳ３３５に進める。また配備アプリ判定部１７４は、接続機器以外の下流機器がない場合、アプリ再配備処理を終了する。
【０１５９】
［ステップＳ３３５］配備アプリ判定部１７４は、ステップＳ３３３で取得した機器名の下流機器において、障害が発生しているか否かを判断する。例えば配備アプリ判定部１７４は、配備先機器状態テーブル１５１から、配備先機器としてステップＳ３３３で取得した機器名が設定されたレコードを取得する。そして配備アプリ判定部１７４は、取得したレコードの障害発生フラグの値が「１」であれば、該当する下流機器で障害が発生していると判断する。配備アプリ判定部１７４は、障害が発生している場合、処理をステップＳ３３６に進める。また配備アプリ判定部１７４は、障害が発生していなければ、アプリ再配備処理を終了する。
【０１６０】
［ステップＳ３３６］配備アプリ判定部１７４は、配備先機器状態テーブル１５１から、障害が発生している下流機器に配備済みの分配アプリの名称を取得する。例えば配備アプリ判定部１７４は、ステップＳ３３５で取得したレコードの配備済みアプリに設定されているアプリ名を、再配備対象アプリのアプリ名として取得する。配備アプリ判定部１７４は、取得したアプリ名と、接続機器の機器名とを、配備済みアプリ再配備部１７５に通知する。
【０１６１】
［ステップＳ３３７］配備済みアプリ再配備部１７５は、接続機器に、再配備対象アプリを配備する。例えば配備済みアプリ再配備部１７５は、デバイス管理テーブル１１１を参照し、接続機器の機器名に対応するＩＰアドレスなどの情報を取得する。また配備済みアプリ再配備部１７５は、再配備対象アプリのアプリ名に対応する分配アプリフローデータを、配備済みアプリ記憶部１３０から取得する。そして配備済みアプリ再配備部１７５は、接続機器にアクセスし、取得した分配アプリフローデータの配備処理を行う。すなわち配備済みアプリ再配備部１７５は、取得した分配アプリフローデータを接続機器にコピーし、接続機器に対して、分配アプリフローデータに基づく処理の実行を開始させる。
【０１６２】
このようにして、障害が発生した配備先機器の代替の配備先機器が接続されると、障害が発生した配備先機器に配備されていた分配アプリが、代替の配備先機器に自動で配備される。その結果、配備先機器の障害によるサービスの停止期間の長期化を抑止することができる。
【０１６３】
また分配アプリを配備した配備先機器が故障しても、故障した配備先機器に配備された分配アプリを再配備すればよく、全体アプリから生成されたすべての分配アプリの再配備を行わずにすむ。すなわちアプリ開発サーバ１００は、分配アプリ生成・配備フェーズにおいて生成した複数の分配アプリを、複数の配備先機器に配備する。その後、ＩｏＴアプリが動作する配備先機器がネットワークに接続されたとき、アプリ開発サーバ１００が、システム構築フェーズにおいて、配備先機器間の機器接続情報（＝配信経路）を構築して保持する。またアプリ開発サーバ１００は、運用フェーズにおいて、新たに配備先機器がネットワークに接続されたことを検知すると、接続された配備先機器と上流機器が同じ配備先機器のうち、障害が発生している配備先機器を特定する。そしてアプリ開発サーバ１００は、特定した配備先機器に配備した分配アプリを、新規に接続した配備先機器に配備する。
【０１６４】
これにより全体アプリから生成されるすべての分配アプリではなく、障害が発生した配備先機器に配備した分配アプリのみを新規に接続した配備先機器に再配備することが可能になる。すなわち、いずれかの配備先機器で正常に動作している分配アプリの入れ替えは不要である。その結果、管理者の配備コストの削減、またはサービス停止による利用者の利便性低下を防ぐことが可能となる。
【０１６５】
なおシステムの管理者は、障害が発生した配備先機器の代替の配備先機器に、例えば故障した配備先機器と同じＩＰアドレスを設定する。これにより代替の配備先機器に分配アプリを再配備しても、分配アプリの内容を変更せずに、代替の配備先機器が、障害が発生した配備先機器の代わりに他の機器と通信できる。
【０１６６】
また分配アプリを実行する配備先機器同士がＭＱＴＴで通信する場合がある。ＭＱＴＴによる通信では、ＭＱＴＴのトピックが通信識別子となり、再配備した分配アプリにも、障害が発生した配備先機器に配備されていたときの同じトピックが設定されている。したがって、代替の配備先機器は、配備された分配アプリに設定されたトピックにより、障害が発生した配備先機器の代わりとして、他の機器との間でＭＱＴＴによる通信を行うことができる。
【０１６７】
〔その他の実施の形態〕
第２の実施の形態では分散環境上で動作するＩｏＴアプリの部分的な機能を実現する分配アプリの再配備の例を示したが、同様の処理により他のアプリを再配備することも可能である。
【０１６８】
以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。
【符号の説明】
【０１６９】
１  接続情報
２  ソフトウェア情報
３ａ〜３ｅ  機器
１０  情報処理装置
１１  記憶部
１２  処理部
【図１】
2020149480.tif 000003
【図２】
2020149480.tif 000004
【図３】
2020149480.tif 000005
【図４】
2020149480.tif 000006
【図５】
2020149480.tif 000007
【図６】
2020149480.tif 000008
【図７】
2020149480.tif 000009
【図８】
2020149480.tif 000010
【図９】
2020149480.tif 000011
【図１０】
2020149480.tif 000012
【図１１】
2020149480.tif 000013
【図１２】
2020149480.tif 000014
【図１３】
2020149480.tif 000015
【図１４】
2020149480.tif 000016
【図１５】
2020149480.tif 000017
【図１６】
2020149480.tif 000018
【図１７】
2020149480.tif 000019
【図１８】
2020149480.tif 000020
【図１９】
2020149480.tif 000021
【図２０】
2020149480.tif 000022
【図２１】
2020149480.tif 000023
【図２２】
2020149480.tif 000024
【図２３】
2020149480.tif 000025
【図２４】
2020149480.tif 000026
【図２５】
2020149480.tif 000027