JP6547580B2 - 分散制御方法、分散制御システム、および分散制御プログラム - Google Patents

Description

本発明は、分散制御方法、分散制御システム、および分散制御プログラムに関する。

従来、複数の通知装置の各通知装置が、複数の事象のある事象を検出する検出装置と協働して、複数の事象に応じた処理を分割した各処理を実行することにより、複数の通知装置が分散処理を実行する技術がある。

関連する先行技術として、例えば、発行−購読ネットワークに関して、通知の伝送における失敗を示す指示情報を受け取る処理およびこの指示情報に応じて通知を再送する技術がある。また、あるノードが既に参加している論理チャンネルから離脱する場合、あるノードは、自らの論理チャンネルのオーナを管理するテーブルを検索し、検索されたオーナに対して離脱要求を示すデータをユニキャスト送信する技術がある。また、リクエストされた肯定応答に応じて時宜を得た肯定応答を受信すると、その肯定応答に関連するすべての未処理メッセージを再送待ち行列から除去する技術がある。

特開２００９−１６３７５３号公報 特開２０１１−５３９７８号公報 特開２００１−１８６２１０号公報 特開２０１１−７２００４号公報

しかしながら、従来技術によれば、複数の通知装置の各通知装置が、複数の事象のある事象を検出する検出装置と協働して、複数の事象に応じた処理を分割した各処理を実行することにより複数の通知装置が実行する分散処理を継続させることができない場合がある。

例えば、分散処理として、ある検出装置がある事象を検出した場合、ある検出装置に接続するある通知装置が、ある事象の検出を他の通知装置に通知し、他の通知装置が、ある事象の検出に応じた処理として他の事象の検出の有無を他の検出装置に問い合わせる。このような場合に、他の検出装置が移動する場合があり、他の検出装置が移動すると、分散処理を継続させることができない場合がある。具体的には、ある通知装置と、他の検出装置の移動元の通知装置と、他の検出装置の移動先の通知装置とが、他の検出装置がどこから移動したか特定することができず、分散処理を継続させることができなくなる。

具体的には、移動先の通知装置は、移動元の通知装置を特定することはできない。また、移動元の通知装置は、他の検出装置と通信できなくなるが、通信の混雑が生じた等により他の検出装置と通信できなかっただけなのか、または他の検出装置の電源が供給されていなかったのか、または他の検出装置が移動したのか特定することはできない。また、ある通知装置は、ある事象の検出を移動元の通知装置に通知すると、ある事象の検出に応じた処理を実行することができない旨の否定応答を受信するが、否定応答では、他の検出装置が移動したか否かは特定できない。

１つの側面では、本発明は、複数の通知装置の各通知装置が、複数の事象のある事象を検出する検出装置と協働して、複数の事象に応じた処理を分割した各処理を実行することにより複数の通知装置が実行する分散処理を継続させることができる分散制御方法、分散制御システム、および分散制御プログラムを提供することを目的とする。

本発明の一側面によれば、それぞれ異なる位置に配置された複数の通知装置と、複数の通知装置のうちの自装置の位置に応じた通知装置に事象の検出を通知する検出装置とを含む分散制御システムにおける第１の事象を検出する検出装置に接続した第１の通知装置が、第１の事象を検出する検出装置から第１の事象の検出を受信した場合、第２の事象を検出する検出装置に接続した第２の通知装置の識別情報と第１の事象の識別情報とを対応付けた通知先情報を参照して、第１の事象の検出を第２の通知装置に通知し、第２の通知装置から第１の事象の検出に応じた処理を実行することができない旨の否定応答を受信した場合、第１の事象の識別情報と第２の通知装置の識別情報とを対応付けて否定応答情報に記憶し、第２の事象を検出する検出装置に接続した第３の通知装置から第１の事象の検出の通知の依頼を受信したことに応じて、否定応答情報に第１の事象の識別情報が含まれるか否かを判断し、否定応答情報に第１の事象の識別情報が含まれると判断した場合、通知先情報と否定応答情報とから、第１の事象の識別情報に対応付けられた第２の通知装置の識別情報を削除する分散制御方法、分散制御システム、および分散制御プログラムが提案される。

本発明の一態様によれば、複数の通知装置の各通知装置が、複数の事象のある事象を検出する検出装置と協働して、複数の事象に応じた処理を分割した各処理を実行することにより複数の通知装置が実行する分散処理を継続させることができるという効果を奏する。

図１は、本実施の形態にかかる分散制御システム１００の動作例を示す説明図である。 図２は、分散制御システム１００の一例を示す説明図である。 図３は、サーバのハードウェア構成例を示す説明図である。 図４は、携帯端末１０２のハードウェア構成例を示す説明図である。 図５は、条件判定の分散処理の一例を示す説明図である。 図６は、携帯端末１０２への条件情報の設定例を示す説明図である。 図７は、Ｐｕｂ／Ｓｕｂ技術を用いた条件判定の分散処理の実行例を示す説明図である。 図８は、ＣＣＮ１０１の機能構成例を示す説明図である。 図９は、Ｓｕｂｓｃｒｉｂｅｒリスト８１１の記憶内容の一例を示す説明図である。 図１０は、ＣＣＮ−Ｓｕｂｓｃｒｉｂｅ数リスト８１２の記憶内容の一例を示す説明図である。 図１１は、再送信待ちリスト８１３の記憶内容の一例を示す説明図である。 図１２は、Ｐｕｂｌｉｓｈの後にＳｕｂｓｃｒｉｂｅが通知される場合のメッセージ送信例を示す説明図である。 図１３は、ＳＵＳ２０１からのＳｕｂｓｃｒｉｂｅ受信時処理手順の一例を示すフローチャートである。 図１４は、第１のＰｕｂｌｉｓｈ処理手順の一例を示すフローチャートである。 図１５は、Ｒｅｇｉｓｔｅｒおよび条件設定要求受信処理手順の一例を示すフローチャートである。 図１６は、ＣＣＮ１０１からのＳｕｂｓｃｒｉｂｅ受信時処理手順の一例を示すフローチャートである。 図１７は、Ｐｕｂｌｉｓｈの前にＳｕｂｓｃｒｉｂｅが通知される場合のメッセージ送信例を示す説明図である。 図１８は、第２のＰｕｂｌｉｓｈ処理手順の一例を示すフローチャートである。 図１９は、Ｅｘｐｉｒｅ時刻到来時の各リストの記憶内容の一例を示す説明図（その１）である。 図２０は、Ｅｘｐｉｒｅ時刻到来時の各リストの記憶内容の一例を示す説明図（その２）である。 図２１は、Ｅｘｐｉｒｅ時刻到来時処理手順の一例を示すフローチャートである。

以下に図面を参照して、開示の分散制御方法、分散制御システム、および分散制御プログラムの実施の形態を詳細に説明する。

図１は、本実施の形態にかかる分散制御システム１００の動作例を示す説明図である。分散制御システム１００は、フィールドの属性が何らかの条件を満たした際に利用者に通知するサービスを提供するシステムである。分散制御システム１００は、複数の通知装置と、自装置の位置に応じた通知装置に事象の検出を通知する検出装置とを含む。分散制御システム１００に含まれる他の装置については、図２で説明する。複数の通知装置は、フィールドの複数の箇所の各箇所に配置されており、利用者から受け付けた条件が成立したら、条件で指定された情報を付与して利用者に通知する。以下、通知装置を、ＣＣＮ（Ｃｏｎｄｉｔｉｏｎ Ｃｈｅｃｋ Ｎｏｄｅ）と称する。

検出装置は、事象を検出する装置である。例えば、検出装置は、携帯端末やラップトップＰＣ等である。以下の例では、検出装置が、携帯端末であるとして説明する。事象とは、観察によって得られる結果である。例えば、事象は、携帯端末が有するセンサによって取得することができる。事象の検出例としては、携帯端末が有する温度センサによって測定された温度が所定の閾値以上となった場合や、携帯端末の有する音センサによって測定された音圧が所定の閾値以上となった場合である。または、事象の検出を、単に、携帯端末が有する温度センサから温度を取得したとしてもよい。または、携帯端末が有する温度センサから温度を取得してＣＣＮに取得した温度を通知し、ＣＣＮが通知を受けた温度と所定の閾値を比較して、通知を受けた温度が所定の閾値以上となった場合に、事象を検出したとしてもよい。

フィールドは、例えば、工場や、圃場等である。例えば、フィールドが工場であるとする。そして、通常の状態では工場内の空調設備の電源はオンとなっているが、工場内のある部屋の温度がある温度以上であり、かつ、工場内の別の部屋の温度がある温度以下である場合には、工場内の空調設備の電源をオフにしたいとする。この場合、工場内に分散制御システム１００を適用することにより、管理者は、工場内のある部屋の温度がある温度以上であり、かつ、工場内の別の部屋の温度がある温度以下である場合に、通知を受けることができる。通知を受けた管理者は、工場内の空調設備の電源をオフにすることができる。

また、他の例として、フィールドが複数の圃場であるとする。そして、通常の状態では複数の圃場に農薬を散布しているが、複数の圃場のうちのある圃場の温度がある温度以上であり、かつ、複数の圃場の別の圃場の温度がある温度以下ならば農薬を散布しないとする。この場合、複数の圃場に分散制御システム１００を適用することにより、複数の圃場の管理者は、ある圃場の温度がある温度以上であり、かつ、別の圃場の温度がある温度以下である場合に、通知を受けることができる。通知を受けた管理者は、農薬の散布を停止することができる。

このようなサービスを提供するために、分散制御システム１００は、複数のＣＣＮが、携帯端末と協働して、複数の事象に応じた処理を分割した各処理を実行することにより実現する分散処理を行う。例えば、ある携帯端末がある事象を検出した場合、ある携帯端末に接続するあるＣＣＮが、ある判定処理が成立したとして、ある事象の検出を他のＣＣＮに通知する。ある事象の検出の通知を受けた他のＣＣＮは、ある事象の検出に応じた処理として他の判定処理を行う。そして、他のＣＣＮは、条件判定処理の中で、他の事象の検出の有無を他の携帯端末に問い合わせる。ここで、他のＣＣＮが、他の携帯端末と通信不可能であると、分散処理を継続させることができなくなる。そこで、他のＣＣＮは、他の携帯端末と通信不可能である場合には、所定回数同じ通知を行う。この場合、携帯端末が多いほど、同じ通知が多く発生することになる。

また、他の携帯端末が移動する場合があり、他の携帯端末が移動すると、分散処理を継続させることができない場合がある。具体的には、あるＣＣＮと、他の携帯端末の移動元のＣＣＮと、他の携帯端末の移動先のＣＣＮとが、他のＣＣＮがどこから移動したか特定することができず、分散処理を継続させることができなくなる。

具体的には、移動先のＣＣＮは、移動元のＣＣＮを特定することはできない。また、移動元のＣＣＮは、他の携帯端末と通信できなくなるが、通信の混雑が生じた等により他の携帯端末と通信できなかっただけなのか、または他の携帯端末の電源が供給されていなかったのか、または他の携帯端末が移動したのか特定することはできない。また、あるＣＣＮは、ある事象の検出を移動元のＣＣＮに通知すると、ある事象の検出に応じた処理を実行することができない旨の否定応答を受信するが、否定応答では、他の携帯端末が移動したか否かは特定できない。また、他の携帯端末は、ＣＣＮの代表ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）しか記憶していない。

そこで、本実施の形態では、あるＣＣＮが、判定処理内のある条件の成立を通知した移動元のＣＣＮから否定応答を受け、移動先のＣＣＮからある条件の成立の通知の依頼を受けたら、ある条件の成立時の通知先を移動先のＣＣＮに変更することについて説明する。

具体的には、図１を用いて分散制御システム１００の動作例について説明する。図１に示す分散制御システム１００は、ＣＣＮ１０１＃１〜＃３と、携帯端末１０２＃Ａ、＃Ｂとを含む。分散制御システム１００の全体については、図２で説明する。また、携帯端末１０２＃Ａ、Ｂは、事象の検出に用いるセンサとして、それぞれ、温度センサ１０３＃Ａ、Ｂを有する。ＣＣＮ１０１＃１、２は、Ｌｏｃａｌｎｅｔ１により接続する。また、ＣＣＮ１０１＃３は、Ｌｏｃａｌｎｅｔ２により接続する。Ｌｏｃａｌｎｅｔ１、２は、互いに接続する。

ここで、図１に示すＣＣＮ１０１＃１は、分散処理の一部の処理となる判定処理が示された条件情報Ｃ１を記憶する。条件情報Ｃ１には、「携帯端末１０２＃Ａの温度が３０度より大きい」という第１の事象を検出した場合、ＣＣＮ１０１＃２に第１の事象の検出を通知する処理を行うことが示されている。同様に、ＣＣＮ１０１＃２は、分散処理の一部の処理となる判定処理が示された条件情報Ｃ２を記憶する。条件情報Ｃ２には、ＣＣＮ１０１＃１から第１の事象の検出を受信し、かつ、「携帯端末１０２＃Ｂの温度が２５度未満」という第２の事象を検出した場合、利用者に通知するという処理を行うことが示されている。

以下、説明を簡略化するため、「＃数字」の記号が付与された符号は、「ＣＣＮ１０１＃数字」に関するものであるとする。また、「＃アルファベット」の記号が付与された符号は、「携帯端末１０２＃アルファベット」に関するものであるとする。

また、ＣＣＮ１０１＃１〜３は、それぞれ、フィールドｆを分割した領域に配置される。また、図１の例では、携帯端末１０２＃Ａは、ＣＣＮ１０１＃１の領域に存在する。従って、携帯端末１０２＃Ａは、自装置の位置に基づき、最も近い位置にあるＣＣＮ１０１＃１に接続する。同様に、携帯端末１０２＃Ｂは、自装置の位置に基づき、最も近い位置にあるＣＣＮ１０１＃２に接続する。以下の説明において、携帯端末１０２が、あるＣＣＮ１０１の領域に存在する場合、「あるＣＣＮ１０１の配下の位置にある携帯端末１０２」と呼称する場合がある。ＣＣＮ１０１＃１と携帯端末１０２＃Ａとは、無線または有線により接続される。同様に、ＣＣＮ１０１＃２と携帯端末１０２＃Ｂとは、無線または有線により接続される。

また、ＣＣＮ１０１＃１は、事象の検出を通知する通知先を管理する通知先情報１１１＃１を記憶する。ここで、通知先情報１１１には、事象の検出の通知の依頼を受けた装置の識別情報と、事象を識別する情報とが対応付けて格納される。事象の検出の通知の依頼を、以下、「購読」と称する。購読を行う装置は、事象の検出の通知先となる装置そのものである場合もあるし、事象の検出の通知先となる装置とは別の装置である場合もある。

この状態で、図１の上部における（１）で示すように、携帯端末１０２＃Ｂが、ＣＣＮ１０１＃２の配下の位置から、ＣＣＮ１０１＃３の配下の位置に移動したとする。そして、携帯端末１０２＃Ｂが移動した後、図１の上部における（２）で示すように、第１の通知装置となるＣＣＮ１０１＃１が、携帯端末１０２＃Ａにアクセスして、「携帯端末１０２＃Ａの温度が３０度より大きい」という第１の事象を検出したとする。

第１の事象を検出した場合、ＣＣＮ１０１＃１は、図１の上部における（３）で示すように、第１の事象の検出を第２の通知装置となるＣＣＮ１０１＃２に通知する。通知を受けたＣＣＮ１０１＃２は、第１の事象の検出に応じた処理を実行するため、携帯端末１０２＃Ｂにアクセスしようとするが、携帯端末１０２＃Ｂは既に移動済であるため、アクセスできない。従って、ＣＣＮ１０１＃２は、予め指定された回数だけリトライした後、図１の上部における（４）で示すように、第１の事象の検出に応じた処理を実行することができない旨の否定応答（ｎａｃｋ）を通知する。

ｎａｃｋを受信した場合、ＣＣＮ１０１＃１は、第１の事象の識別情報とＣＣＮ１０１＃２の識別情報とを対応付けて、否定応答情報１１２＃１に格納する。ＣＣＮ１０１＃１は、否定応答情報１１２＃１を参照して、第１の事象の検出の再送を行う。

次に、図１の下部における（５）で示すように、ＣＣＮ１０１＃１は、第３の通知装置となるＣＣＮ１０１＃３から第１の事象の検出の購読を受ける。ここで、ＣＣＮ１０１＃３は、条件情報Ｃ２に基づいて、ＣＣＮ１０１＃１に第１の事象の検出の購読を送信する。ＣＣＮ１０１＃３が条件情報Ｃ２の取得する方法については、図６で説明する。

そして、第１の事象の検出の購読を受けることに応じて、図１の下部における（６）で示すように、ＣＣＮ１０１＃１は、否定応答情報１１２＃１に含まれる、ＣＣＮ１０１＃２の識別情報を削除できるか否かを判断する。例えば、ＣＣＮ１０１＃１は、事象ごとに、購読を受けた数と、否定応答情報１１２＃１に含まれる否定応答を送信した装置の数とを比較し、一致した場合に、ＣＣＮ１０１＃２の識別情報を削除できると判断する。

または、図１の例では、第１の事象を購読するＣＣＮ１０１が分散制御システム１００内で同時に１つしかないことが予めわかっていたとする。例えば、利用者が指定した条件を分割した装置が、第１の事象の検出の通知を１つのＣＣＮ１０１にすればよいと判断できたときである。このような場合、ＣＣＮ１０１＃３から第１の事象の検出の購読を受けた場合、ＣＣＮ１０１＃１は、否定応答情報１１２に、第１の事象の識別情報が含まれているか判断する。そして、否定応答情報１１２に、第１の事象の識別情報が含まれている場合に、ＣＣＮ１０１＃２の識別情報を削除できると判断する。

図１の例では、ＣＣＮ１０１＃１は、ＣＣＮ１０１＃２の識別情報を削除できると判断し、図１の下部における（７）で示すように、通知先情報１１１と否定応答情報１１２とから第１の事象に対応付けられたＣＣＮ１０１＃２の識別情報を削除する。これにより、分散制御システム１００は、分散処理を継続することができる。次に、図２を用いて、分散制御システム１００全体について説明する。

図２は、分散制御システム１００の一例を示す説明図である。分散制御システム１００は、サービス利用者サーバ（ＳＵＳ：Ｓｅｒｖｉｃｅ Ｕｓｅｒ Ｓｅｒｖｅｒ）２０１と、条件管理サーバ２０２と、位置管理サーバ２０３と、ＣＣＮ１０１＃１〜６と、携帯端末１０２＃Ａ、Ｂとを含む。また、条件管理サーバ２０２、位置管理サーバ２０３、ＣＣＮ１０１＃１〜６は、Ｗｉｄｅ Ａｒｅａ ＮＷによりそれぞれ接続する。また、ＣＣＮ１０１＃１、２は、Ｌｏｃａｌｎｅｔ１により接続する。また、ＣＣＮ１０１＃３、４は、Ｌｏｃａｌｎｅｔ２により接続する。また、ＣＣＮ１０１＃５、６は、Ｌｏｃａｌｎｅｔ３により接続する。Ｗｉｄｅ Ａｒｅａ ＮＷは、Ｌｏｃａｌｎｅｔ１〜３と接続する。

ＳＵＳ２０１は、利用者から条件を受け付けるサーバである。ＳＵＳ２０１は、インターネット２１１を経由して、ＣＣＮ１０１＃１〜６、条件管理サーバ２０２、位置管理サーバ２０３と接続する。

位置管理サーバ２０３は、利用者の携帯端末１０２の位置を管理する。条件管理サーバ２０２は、位置管理サーバ２０３が有する携帯端末１０２の位置情報に用いるＳＵＳ２０１が受け付けた条件を分割し、分割した条件を携帯端末１０２近傍のＣＣＮ１０１に配布する。ここで、条件管理サーバ２０２は、条件が成立する際には、可能な限り早く通知できるように、条件を分割する。また、条件管理サーバ２０２は、条件判定に用いる監視情報の収集や配信を可能なトラフィックコストで行えるように、条件を分割する。例えば、条件管理サーバ２０２は、通信コストとして、ホップ数が小さくなるように、条件を分割する。従って、条件管理サーバ２０２は、条件成立後の通知が一定時間内で行え、かつ、分散制御システム１００にかかるトラフィックが最小となるように、条件を分割する。

ＣＣＮ１０１＃１〜６は、それぞれ、フィールドｆを分割した領域に配置される。また、図２の例では、携帯端末１０２＃Ａは、ＣＣＮ１０１＃１の領域に存在する。また、携帯端末１０２＃Ｂは、ＣＣＮ１０１＃３の領域に存在する。

図３は、サーバのハードウェア構成例を示す説明図である。ここで、サーバとは、図１に示したＣＣＮ１０１と、図２に示したＳＵＳ２０１と、条件管理サーバ２０２と、位置管理サーバ２０３と、である。図３において、サーバは、ＣＰＵ３０１と、ＲＯＭ（Ｒｅａｄ−Ｏｎｌｙ Ｍｅｍｏｒｙ）３０２と、ＲＡＭ３０３と、を含む。また、サーバは、ディスクドライブ３０４およびディスク３０５と、通信インターフェース３０６と、を含む。また、ＣＰＵ３０１〜ディスクドライブ３０４、通信インターフェース３０６はバス３０７によってそれぞれ接続される。

ＣＰＵ３０１は、サーバの全体の制御を司る演算処理装置である。また、サーバは、複数のＣＰＵを有してもよい。ＲＯＭ３０２は、ブートプログラムなどのプログラムを記憶する不揮発性メモリである。ＲＡＭ３０３は、ＣＰＵ３０１のワークエリアとして使用される揮発性メモリである。

ディスクドライブ３０４は、ＣＰＵ３０１の制御に従ってディスク３０５に対するデータのリードおよびライトを制御する制御装置である。ディスクドライブ３０４には、例えば、磁気ディスクドライブ、光ディスクドライブ、ソリッドステートドライブなどを採用することができる。ディスク３０５は、ディスクドライブ３０４の制御で書き込まれたデータを記憶する不揮発性メモリである。例えばディスクドライブ３０４が磁気ディスクドライブである場合、ディスク３０５には、磁気ディスクを採用することができる。また、ディスクドライブ３０４が光ディスクドライブである場合、ディスク３０５には、光ディスクを採用することができる。また、ディスクドライブ３０４がソリッドステートドライブである場合、ディスク３０５には、半導体素子によって形成された半導体メモリ、いわゆる半導体ディスクを採用することができる。

通信インターフェース３０６は、ネットワークと内部のインターフェースを司り、他の装置からのデータの入出力を制御する制御装置である。具体的に、通信インターフェース３０６は、通信回線を通じてネットワークを介して他の装置に接続される。通信インターフェース３０６には、例えば、モデムやＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）アダプタなどを採用することができる。

また、分散制御システム１００の管理者が、サーバを直接操作する場合、サーバは、ディスプレイ、キーボード、マウスといったハードウェアを有してもよい。

図４は、携帯端末１０２のハードウェア構成例を示す説明図である。図４において、携帯端末１０２は、ＣＰＵ４０１と、ＲＯＭ４０２と、ＲＡＭ４０３と、ディスクドライブ４０４と、ディスク４０５と、通信インターフェース４０６と、ディスプレイ４０７と、タッチパネル４０８と、温度センサ４０９と、を有する。また、ＣＰＵ４０１〜ディスクドライブ４０４、通信インターフェース４０６〜温度センサ４０９は、バス４１０によってそれぞれ接続される。

ここで、ＣＰＵ４０１は、携帯端末１０２の全体の制御を司る。ＲＯＭ４０２は、ブートプログラムなどのプログラムを記憶する。ＲＡＭ４０３は、ＣＰＵ４０１のワークエリアとして使用される。ディスクドライブ４０４は、ＣＰＵ４０１の制御に従ってディスク４０５に対するデータのリード／ライトを制御する。ディスク４０５は、ディスクドライブ４０４の制御で書き込まれたデータを記憶する。ディスクドライブ４０４には、例えば、ソリッドステートドライブ等を採用することができる。ディスクドライブ４０４がソリッドステートドライブである場合、ディスク４０５には、半導体メモリ、いわゆる半導体ディスクを採用することができる。

通信インターフェース４０６は、通信回線を通じてネットワークに接続され、ネットワークを介して他のコンピュータに接続される。そして、通信インターフェース４０６は、ネットワークと内部のインターフェースを司り、他のコンピュータからのデータの入出力を制御する。

ディスプレイ４０７は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。ディスプレイ４０７は、例えば、ＴＦＴ（Ｔｈｉｎ Ｆｉｌｍ Ｔｒａｎｓｉｓｔｏｒ）液晶ディスプレイなどを採用することができる。

タッチパネル４０８は、利用者によるタッチ操作やドラッグ操作を検出する。温度センサ４０９は、携帯端末１０２の周囲の気温を得るセンサである。なお、図５に示した携帯端末１０２は、スマートフォンやタブレット端末である。また、携帯端末１０２は、携帯電話でもよい。また、携帯端末１０２は、音センサ、湿度センサ、光度センサ等といったセンサを有してもよい。また、分散制御システム１００は、携帯端末１０２の代わりに、持ち運び可能なラップトップＰＣを検出装置としてもよい。次に、図５を用いて、条件判定の分散処理の一例を説明する。

図５は、条件判定の分散処理の一例を示す説明図である。ＳＵＳ２０１から登録された条件が、複数個所にある携帯端末１０２の情報で形成される場合、条件管理サーバ２０２は、条件を分割し、分割した条件を携帯端末１０２近傍のＣＣＮ１０１に配布する。これにより、条件管理サーバ２０２は、条件判定を分散させる。

図５の例では、ＳＵＳ２０１から登録された条件情報５０１の内容が、「Ｉｆ 携帯端末１０２＃Ａの温度＞３０度 ＡＮＤ 携帯端末１０２＃Ｂの温度＜２５度 Ｔｈｅｎ 通知（サービス利用者、携帯端末１０２＃Ｂの温度）」であるとする。ここで、携帯端末１０２＃Ａ、Ｂの温度とは、携帯端末１０２＃Ａ、Ｂが有する温度センサが計測した温度を示す。また、通知（サービス利用者、携帯端末１０２＃Ｂの温度）は、サービス利用者に、携帯端末１０２＃Ｂが有する温度センサが計測した温度を通知することを示す。

条件情報５０１を受け付けた条件管理サーバ２０２は、位置管理サーバ２０３から得た携帯端末１０２＃Ａ、Ｂの位置に基づいて、条件情報５０１を、条件情報Ｃ１と条件情報Ｃ２とに分割する。図５で示すように、携帯端末１０２＃Ａは、ＣＣＮ１０１＃１の近傍にあり、携帯端末１０２＃Ｂは、ＣＣＮ１０１＃３の近傍にあるとする。

条件情報Ｃ１の内容は、「Ｉｆ 携帯端末１０２＃Ａの温度＞３０度 Ｔｈｅｎ 通知（ＣＣＮ１０１＃３、Ｃ１）」である。ここで、通知（ＣＣＮ１０１＃３、Ｃ１）は、ＣＣＮ１０１＃３に、条件情報Ｃ１が示す条件が成立したことを通知することを示す。また、条件情報Ｃ２の内容は、「Ｉｆ ＣＣＮ１０１＃１からＣ１が成立したことを受信 ＡＮＤ 携帯端末１０２＃Ｂの温度＜２５度 Ｔｈｅｎ 通知（サービス利用者、携帯端末１０２＃Ｂの温度）」である。次に、図６を用いて、携帯端末１０２への条件情報の設定例について説明する。

図６は、携帯端末１０２への条件情報の設定例を示す説明図である。分散制御システム１００は、携帯端末１０２にも分割した条件情報を記憶させる。そして、携帯端末１０２が、例えば携帯端末１０２の利用者の移動により、現在のＣＣＮ１０１の配下の位置から、他のＣＣＮ１０１の配下の位置に移動するとする。この場合、移動した携帯端末１０２は、移動先のＣＣＮ１０１に、記憶した条件情報を通知する。これにより、条件管理サーバ２０２からＣＣＮ１０１への条件設定処理にかかる負荷を減らすことができる。

具体的には、ＣＣＮ１０１は、条件管理サーバ２０２から条件情報が設定されると、設定した条件情報のＩｆ〜Ｔｈｅｎの間にＩＤが含まれる携帯端末１０２にも条件情報を設定する。また、新たな条件情報が設定されたＣＣＮ１０１は、新たな条件情報のＩｆ〜Ｔｈｅｎの間に他のＣＣＮ１０１のＩＤがあれば、他のＣＣＮ１０１に購読の通知を行う。

図６の例では、携帯端末１０２＃Ｂが、ＣＣＮ１０１＃３の配下の位置からＣＣＮ１０１＃５の配下の位置に移動したとする。移動後、携帯端末１０２＃Ｂは、ＣＣＮ１０１＃５に、条件情報Ｃ２を通知する。条件情報Ｃ２を受信したＣＣＮ１０１＃５は、条件情報Ｃ２のＩｆ〜Ｔｈｅｎの間に“ＣＣＮ１０１＃１から”とあるため、ＣＣＮ１０１＃１に購読の通知を行う。

図７は、Ｐｕｂ／Ｓｕｂ技術を用いた条件判定の分散処理の実行例を示す説明図である。図７では、分散制御システム１００を、Ｐｕｂ／Ｓｕｂ技術を用いて実現する例を示す。Ｐｕｂ／Ｓｕｂ技術は、ＯＳＳ（Ｏｐｅｎ Ｓｏｕｒｃｅ Ｓｏｆｔｗａｒｅ）等でミドルウェア化されており、開発工数を下げるために利用されることが多い。

Ｐｕｂ／Ｓｕｂ技術では、Ｐｕｂｌｉｓｈメッセージと、Ｓｕｂｓｃｒｉｂｅメッセージとを用いる。以下の説明では、Ｐｕｂｌｉｓｈメッセージを、単に、「Ｐｕｂｌｉｓｈ」と呼称する。同様に、Ｓｕｂｓｃｒｉｂｅメッセージを、単に、「Ｓｕｂｓｃｒｉｂｅ」と呼称する。

具体的には、ＣＣＮ１０１上で、Ｐｕｂ／Ｓｕｂサーバアプリ７０１と、センサアダプタアプリ７０２とが動作する。Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、Ｐｕｂ／Ｓｕｂ技術を実現するソフトウェアである。センサアダプタアプリ７０２は、リクエストを受け付けて、あたえられた動作に従って処理をするソフトウェアである。

具体的には、図７に示す（１）の処理において、条件管理サーバ２０２は、Ｓｕｂｓｃｒｉｂｅ（Ｃ１，ＣＣＮ１０１＃３．ａｄｐ）を、ＣＣＮ１０１＃１のＰｕｂ／Ｓｕｂサーバアプリ７０１＃１に通知する。ここで、Ｓｕｂｓｃｒｉｂｅ（）は、図１で説明した購読を行うメッセージである。Ｓｕｂｓｃｒｉｂｅ（）の第１引数は、購読先となる装置が購読する情報の識別情報を示し、Ｐｕｂ／Ｓｕｂ技術では、Ｔｏｐｉｃと称する。Ｓｕｂｓｃｒｉｂｅ（）の第２引数は、購読先となる装置の識別情報を示す。また、ＣＣＮ１０１＃３．ａｄｐは、センサアダプタアプリ７０２＃３を示す。

また、図７に示す（２）の処理において、条件管理サーバ２０２は、Ｓｕｂｓｃｒｉｂｅ（Ｃ２，ＳＵＳ２０１）を、ＣＣＮ１０１＃３のＰｕｂ／Ｓｕｂサーバアプリ７０１＃３に通知する。

次に、図７に示す（３）の処理において、センサアダプタアプリ７０２＃１は、携帯端末１０２＃Ａから、携帯端末１０２＃Ａが有する温度センサが測定した温度を取得する。図７の例では、取得した温度が３５度であり、条件情報Ｃ１に示された３０度を超えたことにより、センサアダプタアプリ７０２＃１は、条件情報Ｃ１が示す条件が成立したと判断する。判断後、センサアダプタアプリ７０２＃１は、図７に示す（４）の処理において、条件情報Ｃ１が成立した際に行う処理として、Ｐｕｂ／Ｓｕｂサーバアプリ７０１＃１に、Ｐｕｂｌｉｓｈ（Ｃ１，３５）を通知する。Ｐｕｂｌｉｓｈ（）は、Ｔｏｐｉｃの通知を行うメッセージである。Ｐｕｂｌｉｓｈ（）の第１引数は、通知するＴｏｐｉｃを示す。Ｐｕｂｌｉｓｈ（）の第２引数は、Ｔｏｐｉｃの内容となる情報を示す。

Ｐｕｂｌｉｓｈ（Ｃ１，３５）を受信したＰｕｂ／Ｓｕｂサーバアプリ７０１＃１は、図７に示す（５）の処理において、Ｐｕｂｌｉｓｈ（Ｃ１，３５）を、センサアダプタアプリ７０２＃３に通知する。

そして、図７に示す（６）の処理において、Ｐｕｂｌｉｓｈ（Ｃ１，３５）を受信したセンサアダプタアプリ７０２＃３は、携帯端末１０２＃Ｂから、携帯端末１０２＃Ｂが有する温度センサが測定した温度を取得する。図７の例では、ＣＣＮ１０１＃１から条件情報Ｃ１が示す条件が成立したことを受信しており、かつ、取得した温度が２０度であるため２５度を下回ることにより、センサアダプタアプリ７０２＃３は、条件情報Ｃ２が示す条件が成立したと判断する。判断後、センサアダプタアプリ７０２＃３は、図７に示す（７）の処理において、条件情報Ｃ２が成立した際に行う処理として、Ｐｕｂ／Ｓｕｂサーバアプリ７０１＃３に、Ｐｕｂｌｉｓｈ（Ｃ２，２０）を通知する。

Ｐｕｂｌｉｓｈ（Ｃ２，２０）を受信したＰｕｂ／Ｓｕｂサーバアプリ７０１＃３は、図７に示す（８）の処理において、Ｐｕｂｌｉｓｈ（Ｃ２，２０）を、ＳＵＳ２０１に通知する。以下では、分散制御システム１００を、Ｐｕｂ／Ｓｕｂ技術を用いて実現した例を用いて説明を行う。

（ＣＣＮ１０１の機能構成例）
図８は、ＣＣＮ１０１の機能構成例を示す説明図である。ＣＣＮ１０１は、制御部８００を有する。制御部８００は、通知部８０１と、格納部８０２と、判断部８０３と、削除部８０４と、送信部８０５と、実行部８０６とを含む。制御部８００は、記憶装置に記憶されたプログラムをＣＰＵ３０１が実行することにより、各部の機能を実現する。記憶装置とは、具体的には、例えば、図３に示したＲＯＭ３０２、ＲＡＭ３０３、ディスク３０５などである。また、各部の処理結果は、ＣＰＵ３０１のレジスタや、ＣＰＵ３０１のキャッシュメモリ等に格納される。

また、ＣＣＮ１０１は、条件情報Ｃ、Ｓｕｂｓｃｒｉｂｅｒリスト８１１、ＣＣＮ−Ｓｕｂｓｃｒｉｂｅ数リスト８１２、再送信待ちリスト８１３にアクセス可能である。条件情報Ｃ、Ｓｕｂｓｃｒｉｂｅｒリスト８１１、ＣＣＮ−Ｓｕｂｓｃｒｉｂｅ数リスト８１２、再送信待ちリスト８１３は、ＲＡＭ３０３、ディスク３０５といった記憶装置に格納されている。ここで、Ｓｕｂｓｃｒｉｂｅｒリスト８１１は、図１に示した通知先情報１１１に相当する。また、再送信待ちリスト８１３は、図１に示した否定応答情報１１２に相当する。

通知部８０１〜削除部８０４は、図１に示すＣＣＮ１０１＃１の機能である。通知部８０１〜削除部８０４の説明では、図７の例を用いて、第１のＴｏｐｉｃを検出する携帯端末１０２が、携帯端末１０２＃Ａであるとし、第２のＴｏｐｉｃを検出する携帯端末１０２が、携帯端末１０２＃Ｂであるとする。そして、携帯端末１０２＃Ｂが、ＣＣＮ１０１＃３の配下の位置からＣＣＮ１０１＃５の配下の位置に移動したとする。

通知部８０１は、第１のＴｏｐｉｃの検出を受信した場合、Ｓｕｂｓｃｒｉｂｅｒリスト８１１を参照して、第１のＴｏｐｉｃのＰｕｂｌｉｓｈをＣＣＮ１０１＃３に通知する。

格納部８０２は、ＣＣＮ１０１＃３から第１のＴｏｐｉｃのＰｕｂｌｉｓｈに応じた処理を実行することができない旨のｎａｃｋを受信した場合、第１のＴｏｐｉｃの識別情報とＣＣＮ１０１＃３の識別情報とを対応付けて再送信待ちリスト８１３に格納する。

判断部８０３は、ＣＣＮ１０１＃５から第１のＴｏｐｉｃの検出のＳｕｂｓｃｒｉｂｅを受信したことに応じて、再送信待ちリスト８１３に第１のＴｏｐｉｃの識別情報が含まれるか否かを判断する。

削除部８０４は、再送信待ちリスト８１３に第１のＴｏｐｉｃの識別情報が含まれると判断した場合、Ｓｕｂｓｃｒｉｂｅｒリスト８１１と再送信待ちリスト８１３とから、第１のＴｏｐｉｃの識別情報に対応付けられたＣＣＮ１０１＃３の識別情報を削除する。

次に、Ｐｕｂｌｉｓｈの後にＳｕｂｓｃｒｉｂｅが通知される場合の機能について説明する。ＣＣＮ１０１＃１が、ｎａｃｋを受信した後にＣＣＮ１０１＃５から第１のＴｏｐｉｃのＳｕｂｓｃｒｉｂｅを受信したとする。Ｓｕｂｓｃｒｉｂｅを受信したことに応じて、判断部８０３は、再送信待ちリスト８１３に含まれる第１のＴｏｐｉｃの識別情報に対応付けられたＣＣＮ１０１の識別情報の数と、Ｓｕｂｓｃｒｉｂｅを送信したＣＣＮ１０１の数とが一致するか否かを判断する。ＴｏｐｉｃごとのＳｕｂｓｃｒｉｂｅを送信したＣＣＮ１０１の数は、ＣＣＮ−Ｓｕｂｓｃｒｉｂｅ数リスト８１２に記憶される。

そして、削除部８０４は、第１のＴｏｐｉｃに関する２つの数が一致すると判断した場合、Ｓｕｂｓｃｒｉｂｅｒリスト８１１と再送信待ちリスト８１３とから、第１のＴｏｐｉｃの識別情報に対応付けられたＣＣＮ１０１＃３の識別情報を削除する。

Ｐｕｂｌｉｓｈの後にＳｕｂｓｃｒｉｂｅが通知される場合については、図１２〜図１６でより詳細に説明する。次に、Ｐｕｂｌｉｓｈの前にＳｕｂｓｃｒｉｂｅが通知される場合の機能について説明する。

通知部８０１は、ｎａｃｋを受信する前にＣＣＮ１０１＃５からＳｕｂｓｃｒｉｂｅを受信した後に、第１のＴｏｐｉｃの検出を受信した場合、第１のＴｏｐｉｃのＰｕｂｌｉｓｈを、ＣＣＮ１０１＃３に加えて、さらに、ＣＣＮ１０１＃５に通知する。

また、判断部８０３は、ｎａｃｋを受信したことに応じて、再送信待ちリスト８１３に含まれる第１のＴｏｐｉｃの識別情報に対応付けられたＣＣＮ１０１の識別情報の数と、Ｓｕｂｓｃｒｉｂｅを送信した通知装置の数とが一致するか否かを判断する。

そして、削除部８０４は、第１のＴｏｐｉｃに関する２つの数が一致すると判断した場合、Ｓｕｂｓｃｒｉｂｅｒリスト８１１と再送信待ちリスト８１３とから、第１のＴｏｐｉｃの識別情報に対応付けられたＣＣＮ１０１＃３の識別情報を削除する。

Ｐｕｂｌｉｓｈの前にＳｕｂｓｃｒｉｂｅが通知される場合については、図１７、図１８でより詳細に説明する。次に、ｎａｃｋを受信した時刻に基づいた期限時刻を超えた場合の機能について説明する。

格納部８０２は、ｎａｃｋを受信した場合、第１のＴｏｐｉｃの識別情報とＣＣＮ１０１＃３の識別情報とｎａｃｋを受信した時刻に基づいた期限時刻を示す値とを対応付けて再送信待ちリスト８１３に格納する。以下、期限時刻を「Ｅｘｐｉｒｅ時刻」と称する。

そして、判断部８０３は、現在時刻が期限時刻となったことに応じて、再送信待ちリスト８１３に含まれる第１のＴｏｐｉｃの識別情報に対応付けられた通知装置の識別情報の数と、依頼を送信した通知装置の数とが一致するか否かを判断する。

次に、削除部８０４は、第１のＴｏｐｉｃに関する２つの数が一致すると判断した場合、Ｓｕｂｓｃｒｉｂｅｒリスト８１１と再送信待ちリスト８１３とから、第１のＴｏｐｉｃの識別情報に対応付けられたＣＣＮ１０１＃３の識別情報を削除する。

Ｅｘｐｉｒｅ時刻を超えた場合については、図１９〜図２１でより詳細に説明する。次に、送信部８０５、実行部８０６の説明を行う。送信部８０５、実行部８０６は、図１に示したＣＣＮ１０１＃２、３の機能である。まず、図１に示したＣＣＮ１０１＃２における機能について説明する。

送信部８０５は、ＣＣＮ１０１＃１から第２のＴｏｐｉｃとは異なる第１のＴｏｐｉｃのＰｕｂｌｉｓｈを受信した場合、条件情報Ｃを参照して、携帯端末１０２＃Ｂに第２のＴｏｐｉｃの検出の有無の送信要求を送信する。ここで、条件情報Ｃは、他のＣＣＮ１０１から他のＴｏｐｉｃの検出を受信し、かつ、いずれかのＴｏｐｉｃを検出したかを示す条件と条件を満たす際の所定の処理とを示す情報である。所定の処理は、どのようなものでもよく、例えば、ＳＵＳ２０１に通知する処理でもよいし、別のＣＣＮ１０１にＰｕｂｌｉｓｈを通知する処理でもよい。

そして、送信部８０５は、送信要求に対する応答がない場合、他のＴｏｐｉｃの検出に対応する処理を実行することができない旨の否定応答をＣＣＮ１０１＃１に送信する。

次に、図１に示したＣＣＮ１０１＃３における機能について説明する。送信部８０５は、条件情報Ｃを記憶しており第２のＴｏｐｉｃを検出する携帯端末１０２＃Ｂと接続してから条件情報Ｃを受信した場合、第１のＴｏｐｉｃのＳｕｂｓｃｒｉｂｅをＣＣＮ１０１＃１に送信する。そして、送信部８０５は、第１のＴｏｐｉｃのＰｕｂｌｉｓｈをＣＣＮ１０１＃１から受信した場合、条件情報Ｃを参照して、第２のＴｏｐｉｃを検出する携帯端末１０２＃Ｂに第２のＴｏｐｉｃの検出の有無の送信要求を送信する。

実行部８０６は、第２のＴｏｐｉｃを検出する携帯端末１０２＃Ｂから第２のＴｏｐｉｃの検出を受信した場合、条件情報Ｃを参照して所定の処理を実行する。

図９は、Ｓｕｂｓｃｒｉｂｅｒリスト８１１の記憶内容の一例を示す説明図である。図９に示すＳｕｂｓｃｒｉｂｅｒリスト８１１は、エントリ９０１−１、２を有する。

Ｓｕｂｓｃｒｉｂｅｒリスト８１１は、Ｔｏｐｉｃと、ＳｕｂｓｃｒｉｂｅｒＩＰというフィールドを含む。Ｔｏｐｉｃフィールドには、ＳｕｂｓｃｒｉｂｅｒＩＰで示される装置が購読する情報の識別情報が格納される。ＳｕｂｓｃｒｉｂｅｒＩＰフィールドには、ＳｕｂｓｃｒｉｂｅｒＩＰで示される装置のＩＰアドレスが格納される。図９の例では、ＳｕｂｓｃｒｉｂｅｒＩＰフィールドには、説明の簡略化のため、装置の名称に符号を付与した文字列が格納される。なお、Ｓｕｂｓｃｒｉｂｅｒリスト８１１とは別のリストにも、ＳｕｂｓｃｒｉｂｅｒＩＰフィールドが存在するものがあるが、全て同様とする。

例えば、エントリ９０１−１は、条件情報Ｃ１が示す条件が成立した場合、条件情報Ｃ１が示す条件が成立したことを示す情報を、ＣＣＮ１０１＃３に送信することを示す。

図１０は、ＣＣＮ−Ｓｕｂｓｃｒｉｂｅ数リスト８１２の記憶内容の一例を示す説明図である。図１０に示すＣＣＮ−Ｓｕｂｓｃｒｉｂｅ数リスト８１２は、エントリ１００１−１を有する。

ＣＣＮ−Ｓｕｂｓｃｒｉｂｅ数リスト８１２は、Ｔｏｐｉｃと、ＣＣＮ−Ｓｕｂｓｃｒｉｂｅ数というフィールドを含む。Ｔｏｐｉｃフィールドには、なんらかの装置が購読する情報の識別情報が格納される。ＣＣＮ−Ｓｕｂｓｃｒｉｂｅ数フィールドには、Ｔｏｐｉｃフィールドに格納された情報を購読する装置の数が格納される。

例えば、エントリ１００１−１は、条件情報Ｃ１が示す条件が成立したことを示す情報の購読先となる装置が１つであることを示す。

図１１は、再送信待ちリスト８１３の記憶内容の一例を示す説明図である。図１１に示す再送信待ちリスト８１３は、エントリ１１０１−１を有する。

再送信待ちリスト８１３は、Ｔｏｐｉｃと、ＳｕｂｓｃｒｉｂｅｒＩＰと、ＰｕｂｌｉｓｈＭｓｇと、Ｅｘｐｉｒｅというフィールドを含む。Ｔｏｐｉｃフィールドには、なんらかの装置が購読する情報の識別情報が格納される。ＳｕｂｓｃｒｉｂｅｒＩＰフィールドには、Ｔｏｐｉｃフィールドに格納された情報を購読する装置のＩＰアドレスが格納される。ＰｕｂｌｉｓｈＭｓｇフィールドには、再送信するメッセージの内容が格納される。Ｅｘｐｉｒｅフィールドには、メッセージの再送信を打ち切る時刻が格納される。

例えば、エントリ１１０１−１は、送信先がＣＣＮ１０１＃３［”ｔｏｐｉｃ”：”Ｃ１”，”ｔｅｍｐ”：”３５”］というメッセージを、２０１４年１２月２８日１８時３０分までは再送することを示す。

次に、携帯端末１０２が移動する際に発生するＰｕｂｌｉｓｈの再送を抑制する３つの例を、それぞれ、図１２〜図１６と、図１７および図１８と、図１９〜図２１とで説明する。ここで、携帯端末１０２が移動する場合、別のＣＣＮ１０１に登録されるだけであり、分散制御システム１００全体で登録されている携帯端末１０２の総数に変化がないという特徴がある。この特徴を利用して、分散制御システム１００は、ｎａｃｋによる再送待ちの数と、新たに届いたＳｕｂｓｃｒｉｂｅの数が一致した場合、ｎａｃｋによる再送待ちを削除することにより、Ｐｕｂｌｉｓｈの再送を抑制する。

（Ｐｕｂｌｉｓｈの後にＳｕｂｓｃｒｉｂｅが通知される場合）
次に、図１２〜図１６を用いて、Ｐｕｂｌｉｓｈの後にＳｕｂｓｃｒｉｂｅが通知される場合に、携帯端末１０２が移動することにより発生するＰｕｂｌｉｓｈの再送を抑制する例を説明する。

図１２は、Ｐｕｂｌｉｓｈの後にＳｕｂｓｃｒｉｂｅが通知される場合のメッセージ送信例を示す説明図である。図１２で示す状態では、携帯端末１０２＃Ｂが、ＣＣＮ１０１＃３配下の位置から、ＣＣＮ１０１＃５配下の位置に移動したとする。このとき、図１２で示す（３）の処理によるＰｕｂｌｉｓｈの後に、携帯端末１０２の移動により発生する図１２で示す（７）の処理によるＳｕｂｓｃｒｉｂｅが通知されたものとする。

図１２に示す（１）の処理において、センサアダプタアプリ７０２＃１は、携帯端末１０２＃Ａから、携帯端末１０２＃Ａが有する温度センサが測定した温度を取得する。図１２の例では、取得した温度が３５度であり、条件情報Ｃ１に示された３０度を超えたことにより、センサアダプタアプリ７０２＃１は、条件情報Ｃ１が示す条件が成立したと判断する。判断後、センサアダプタアプリ７０２＃１は、図１２に示す（２）の処理において、条件情報Ｃ１が成立した際に行う処理として、Ｐｕｂ／Ｓｕｂサーバアプリ７０１＃１に、Ｐｕｂｌｉｓｈ（Ｃ１，３５）を通知する。

Ｐｕｂｌｉｓｈ（Ｃ１，３５）を受信したＰｕｂ／Ｓｕｂサーバアプリ７０１＃１は、第１のＰｕｂｌｉｓｈ処理を実行する。第１のＰｕｂｌｉｓｈ処理については、図１４で示す。そして、Ｐｕｂ／Ｓｕｂサーバアプリ７０１＃１は、第１のＰｕｂｌｉｓｈ処理の一部として、図１２に示す（３）の処理において、Ｐｕｂｌｉｓｈ（Ｃ１，３５）を、センサアダプタアプリ７０２＃３に通知する。

Ｐｕｂｌｉｓｈ（Ｃ１，３５）を受信したセンサアダプタアプリ７０２＃３は、携帯端末１０２＃Ｂが有する温度センサにアクセスしようとする。しかし、携帯端末１０２＃Ｂは移動しており、センサアダプタアプリ７０２＃３は、携帯端末１０２＃Ｂが有する温度センサにアクセスすることはできない。センサアダプタアプリ７０２＃３は、予め指定された回数だけリトライした後、図１２に示す（４）の処理において、Ｐｕｂ／Ｓｕｂサーバアプリ７０１＃１に、ｎａｃｋを通知する。

ｎａｃｋを受信したＰｕｂ／Ｓｕｂサーバアプリ７０１＃１は、第１のＰｕｂｌｉｓｈ処理の一部として、図１２の（５）の処理において、再送待ちの数を１増やす。具体的には、Ｐｕｂ／Ｓｕｂサーバアプリ７０１＃１は、再送信待ちリスト８１３に再送するメッセージを登録する。

そして、図１２に示す（３）の処理より後となった図１２に示す（６）の処理において、Ｒｅｇｉｓｔｅｒおよび条件設定要求を携帯端末１０２＃Ｂから受信したセンサアダプタアプリ７０２＃５は、Ｒｅｇｉｓｔｅｒおよび条件設定要求受信処理を実行する。Ｒｅｇｉｓｔｅｒおよび条件設定要求受信処理については、図１５で示す。そして、Ｒｅｇｉｓｔｅｒおよび条件設定要求受信処理の一部として、図１２に示す（７）の処理において、センサアダプタアプリ７０２＃５は、Ｐｕｂ／Ｓｕｂサーバアプリ７０１＃１にＳｕｂｓｃｒｉｂｅ（Ｃ１）を通知する。

Ｓｕｂｓｃｒｉｂｅ（Ｃ１）を受信したＰｕｂ／Ｓｕｂサーバアプリ７０１＃１は、ＣＣＮ１０１からのＳｕｂｓｃｒｉｂｅ受信時処理を実行する。ＣＣＮ１０１からのＳｕｂｓｃｒｉｂｅ受信時処理については、図１６で示す。そして、ＣＣＮ１０１からのＳｕｂｓｃｒｉｂｅ受信時処理の一部として、図１２に示す（８）の処理により、Ｐｕｂ／Ｓｕｂサーバアプリ７０１＃１は、ｎａｃｋによる再送待ちの数と、新たに届いたＳｕｂｓｃｒｉｂｅの数とを比較する。図１２の例では、ｎａｃｋによる再送待ちの数が１であり、新たに届いたＳｕｂｓｃｒｉｂｅの数が１であるため、一致することになる。従って、この場合、Ｐｕｂ／Ｓｕｂサーバアプリ７０１＃１は、ｎａｃｋによる再送待ちを削除する。

次に、分散制御システム１００で行われる処理を示すフローチャートを、図１３〜図１６を用いて説明する。

図１３は、ＳＵＳ２０１からのＳｕｂｓｃｒｉｂｅ受信時処理手順の一例を示すフローチャートである。ＳＵＳ２０１からのＳｕｂｓｃｒｉｂｅ受信時処理は、ＳＵＳ２０１からＳｕｂｓｃｒｉｂｅを受信した際にＰｕｂ／Ｓｕｂサーバアプリ７０１が行う処理である。例えば、ＳＵＳ２０１からのＳｕｂｓｃｒｉｂｅ受信時処理は、図７で示す（１）や（２）の処理の後、Ｐｕｂ／Ｓｕｂサーバアプリ７０１が実行する。

Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、ＳＵＳ２０１から受信したＳｕｂｓｃｒｉｂｅから、Ｔｏｐｉｃと、ＳｕｂｓｃｒｉｂｅＩＰとを取得する（ステップＳ１３０１）。そして、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、取得したＴｏｐｉｃと、ＳｕｂｓｃｒｉｂｅＩＰとをＳｕｂｓｃｒｉｂｅｒリスト８１１に登録する（ステップＳ１３０２）。ステップＳ１３０２の処理終了後、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、ＳＵＳ２０１からのＳｕｂｓｃｒｉｂｅ受信時処理を終了する。ＳＵＳ２０１からのＳｕｂｓｃｒｉｂｅ受信時処理を実行することにより、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、購読対象となる情報と、購読対象を購読する装置とを対応付けて管理することができる。

図１４は、第１のＰｕｂｌｉｓｈ処理手順の一例を示すフローチャートである。第１のＰｕｂｌｉｓｈ処理は、Ｐｕｂ／Ｓｕｂサーバアプリ７０１が行う処理であり、Ｐｕｂｌｉｓｈを送信する処理である。

Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、Ｐｕｂｌｉｓｈ処理の起動理由を確認する（ステップＳ１４０１）。新規Ｐｕｂｌｉｓｈを受信したことによりＰｕｂｌｉｓｈ処理を起動した場合（ステップＳ１４０１：新規Ｐｕｂｌｉｓｈ受信）、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、ＴｏｐｉｃをキーにＳｕｂｓｃｒｉｂｅｒリスト８１１を検索する（ステップＳ１４０２）。そして、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、Ｓｕｂｓｃｒｉｂｅｒリスト８１１から、キーとしたＴｏｐｉｃに対応したＳｕｂｓｃｒｉｂｅｒＩＰの一覧を取得する（ステップＳ１４０３）。

一方、再送のため定期起動によりＰｕｂｌｉｓｈ処理を起動した場合（ステップＳ１４０１：定期起動）、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、再送信待ちリスト８１３を参照して、ＳｕｂｓｃｒｉｂｅｒＩＰの一覧を取得する（ステップＳ１４０４）。

ステップＳ１４０３、ステップＳ１４０４のうちのいずれか一方の処理終了後、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、ＳｕｂｓｃｒｉｂｅｒＩＰの一覧から、ＳｕｂｓｃｒｉｂｅｒＩＰを一つ選択する（ステップＳ１４０５）。そして、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、選択したＳｕｂｓｃｒｉｂｅｒＩＰへ、Ｐｕｂｌｉｓｈを通知する（ステップＳ１４０６）。そして、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、Ｐｕｂｌｉｓｈに対するａｃｋを受信したか否かを判断する（ステップＳ１４０７）。Ｐｕｂｌｉｓｈに対するｎａｃｋを受信した場合（ステップＳ１４０７：Ｎｏ）、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、Ｐｕｂｌｉｓｈを再送信待ちリスト８１３に登録する（ステップＳ１４０８）。

Ｐｕｂｌｉｓｈに対するａｃｋを受信した場合（ステップＳ１４０７：Ｙｅｓ）、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、ＳｕｂｓｃｒｉｂｅｒＩＰの一覧の全てのＳｕｂｓｃｒｉｂｅｒＩＰにＰｕｂｌｉｓｈを送信したか否かを判断する（ステップＳ１４０９）。ＳｕｂｓｃｒｉｂｅｒＩＰの一覧の中で、Ｐｕｂｌｉｓｈを送信していないＳｕｂｓｃｒｉｂｅｒＩＰがある場合（ステップＳ１４０９：Ｎｏ）、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、ステップＳ１４０５の処理に移行する。一方、ＳｕｂｓｃｒｉｂｅｒＩＰの一覧の全てのＳｕｂｓｃｒｉｂｅｒＩＰにＰｕｂｌｉｓｈを送信した場合（ステップＳ１４０９：Ｙｅｓ）、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、第１のＰｕｂｌｉｓｈ処理を終了する。

第１のＰｕｂｌｉｓｈ処理を実行することにより、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、Ｔｏｐｉｃに登録しているＳｕｂｓｃｒｉｂｅｒへＴｏｐｉｃが示す情報を通知することができる。

図１５は、Ｒｅｇｉｓｔｅｒおよび条件設定要求受信処理手順の一例を示すフローチャートである。Ｒｅｇｉｓｔｅｒおよび条件設定要求受信処理は、携帯端末１０２からＲｅｇｉｓｔｅｒおよび条件設定要求を受信した際に行う処理である。

センサアダプタアプリ７０２は、携帯端末１０２からＲｅｇｉｓｔｅｒおよび条件設定要求を受信した場合、受信したデータに、条件情報が含まれるか否かを判断する（ステップＳ１５０１）。条件情報が含まれる場合（ステップＳ１５０１：Ｙｅｓ）、センサアダプタアプリ７０２は、配下センサリストに、センサＩＤと条件情報とを登録する（ステップＳ１５０２）。ここで、配下センサリストは、ＣＣＮ１０１が記憶するリストであり、配下となる領域に含まれるセンサを管理するリストである。そして、センサアダプタアプリ７０２は、条件情報のＩｆ〜Ｔｈｅｎの間にＣＣＮのＩＤが含まれるか否かを判断する（ステップＳ１５０４）。条件情報のＩｆ〜Ｔｈｅｎの間にＣＣＮのＩＤが含まれる場合（ステップＳ１５０４：Ｙｅｓ）、センサアダプタアプリ７０２は、条件情報のＩｆ〜Ｔｈｅｎの間にＩＤが含まれていたＣＣＮに、条件情報を示すＩＤを引数としたＳｕｂｓｃｒｉｂｅを通知する（ステップＳ１５０５）。

一方、条件情報が含まれない場合（ステップＳ１５０１：Ｎｏ）、センサアダプタアプリ７０２は、配下センサリストに、センサＩＤを登録する（ステップＳ１５０３）。ステップＳ１５０３またはステップＳ１５０５の処理終了後、または、条件情報のＩｆ〜Ｔｈｅｎの間にＣＣＮのＩＤが含まれない場合（ステップＳ１５０４：Ｎｏ）、センサアダプタアプリ７０２は、Ｒｅｇｉｓｔｅｒおよび条件設定要求受信処理を終了する。Ｒｅｇｉｓｔｅｒおよび条件設定要求受信処理を実行することにより、センサアダプタアプリ７０２は、移動してきた携帯端末１０２が条件情報を有する場合に、条件情報が示す条件の一部の成立条件を有する装置にｓｕｂｓｃｒｉｂｅを通知することができる。

図１６は、ＣＣＮ１０１からのＳｕｂｓｃｒｉｂｅ受信時処理手順の一例を示すフローチャートである。ＣＣＮ１０１からのＳｕｂｓｃｒｉｂｅ受信時処理は、他のＣＣＮ１０１からＳｕｂｓｃｒｉｂｅを受信した際にＰｕｂ／Ｓｕｂサーバアプリ７０１が行う処理である。

Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、受信したＳｕｂｓｃｒｉｂｅから、Ｔｏｐｉｃと、ＳｕｂｓｃｒｉｂｅＩＰとを取得する（ステップＳ１６０１）。次に、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、取得したＴｏｐｉｃと、ＳｕｂｓｃｒｉｂｅＩＰとをＳｕｂｓｃｒｉｂｅｒリスト８１１に登録する（ステップＳ１６０２）。そして、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、取得したＴｏｐｉｃに対するＣＣＮ−Ｓｕｂｓｃｒｉｂｅ数をインクリメントする（ステップＳ１６０３）。次に、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、再送信待ちリスト８１３から、Ｔｏｐｉｃに対するエントリ数を計数する（ステップＳ１６０４）。

そして、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、ＣＣＮ−Ｓｕｂｓｃｒｉｂｅ数と再送信待ちリスト８１３のエントリ数とが同一のＴｏｐｉｃがあるか否かを判断する（ステップＳ１６０５）。ＣＣＮ−Ｓｕｂｓｃｒｉｂｅ数と再送信待ちリスト８１３のエントリ数とが同一のＴｏｐｉｃがある場合（ステップＳ１６０５：Ｙｅｓ）、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、再送信待ちリスト８１３から、数が同一のＴｏｐｉｃを有するエントリを削除する（ステップＳ１６０６）。また、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、Ｓｕｂｓｃｒｉｂｅｒリスト８１１から、再送信待ちリスト８１３から削除したエントリに対応するエントリを削除する（ステップＳ１６０７）。そして、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、再送信待ちリスト８１３にあるメッセージを送信する（ステップＳ１６０８）。なお、ステップＳ１６０８について、再送信待ちリスト８１３のエントリ数が０となった場合には、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、メッセージを送信しない。

ステップＳ１６０８の処理終了後、または、ＣＣＮ−Ｓｕｂｓｃｒｉｂｅ数と再送信待ちリスト８１３のエントリ数とが同一のＴｏｐｉｃがない場合（ステップＳ１６０５：Ｎｏ）、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、ＣＣＮ１０１からのＳｕｂｓｃｒｉｂｅ受信時処理を終了する。

ＣＣＮ１０１からのＳｕｂｓｃｒｉｂｅ受信時処理を実行することにより、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、ＣＣＮ−ｓｕｂｓｃｒｉｂｅ数と再送信待ちリスト８１３のエントリ数とが同一であれば、ｎａｃｋによる再送待ちを削除することができる。

（Ｐｕｂｌｉｓｈの前にＳｕｂｓｃｒｉｂｅが通知される場合）
図１７、図１８を用いて、Ｐｕｂｌｉｓｈの前にＳｕｂｓｃｒｉｂｅが通知される場合に、携帯端末１０２が移動することにより発生するＰｕｂｌｉｓｈの再送を抑制する例を説明する。

図１７は、Ｐｕｂｌｉｓｈの前にＳｕｂｓｃｒｉｂｅが通知される場合のメッセージ送信例を示す説明図である。図１２で示す状態では、携帯端末１０２＃Ｂが、ＣＣＮ１０１＃３配下の位置から、ＣＣＮ１０１＃５配下の位置に移動したとする。このとき、図１７で示す（５）の処理によるＰｕｂｌｉｓｈの前に、携帯端末１０２の移動により発生する図１７で示す（２）の処理によるＳｕｂｓｃｒｉｂｅが通知されたものとする。

図１７に示す（１）の処理において、Ｒｅｇｉｓｔｅｒおよび条件設定要求を携帯端末１０２＃Ｂから受信したセンサアダプタアプリ７０２＃５は、Ｒｅｇｉｓｔｅｒおよび条件設定要求受信処理を実行する。そして、Ｒｅｇｉｓｔｅｒおよび条件設定要求受信処理の一部として、図１７に示す（２）の処理において、センサアダプタアプリ７０２＃５は、Ｐｕｂ／Ｓｕｂサーバアプリ７０１＃１にＳｕｂｓｃｒｉｂｅ（Ｃ１）を通知する。

Ｓｕｂｓｃｒｉｂｅ（Ｃ１）を受信したＰｕｂ／Ｓｕｂサーバアプリ７０１＃１は、ＣＣＮ１０１からのＳｕｂｓｃｒｉｂｅ受信時処理を実行する。次に、図１７に示す（３）の処理において、センサアダプタアプリ７０２＃１は、携帯端末１０２＃Ａから、携帯端末１０２＃Ａが有する温度センサが測定した温度を取得する。図１７の例では、取得した温度が３５度であり、条件情報Ｃ１に示された３０度を超えたことにより、センサアダプタアプリ７０２＃１は、条件情報Ｃ１が示す条件が成立したと判断する。判断後、センサアダプタアプリ７０２＃１は、図１７に示す（４）の処理において、条件情報Ｃ１が成立した際に行う処理として、Ｐｕｂ／Ｓｕｂサーバアプリ７０１＃１に、Ｐｕｂｌｉｓｈ（Ｃ１，３５）を通知する。

Ｐｕｂｌｉｓｈ（Ｃ１，３５）を受信したＰｕｂ／Ｓｕｂサーバアプリ７０１＃１は、第２のＰｕｂｌｉｓｈ処理を実行する。第２のＰｕｂｌｉｓｈ処理については、図１８で示す。そして、Ｐｕｂ／Ｓｕｂサーバアプリ７０１＃１は、第２のＰｕｂｌｉｓｈ処理の一部として、図１７に示す（５）の処理において、Ｐｕｂｌｉｓｈ（Ｃ１，３５）を、センサアダプタアプリ７０２＃３とセンサアダプタアプリ７０２＃５とに通知する。

Ｐｕｂｌｉｓｈ（Ｃ１，３５）を受信したセンサアダプタアプリ７０２＃５は、携帯端末１０２＃Ｂが有する温度センサにアクセスし、ａｃｋをＰｕｂ／Ｓｕｂサーバアプリ７０１＃１に送信する。引き続き、センサアダプタアプリ７０２＃５は、条件情報Ｃ２が示す条件が成立するか否かを判定する。

一方、Ｐｕｂｌｉｓｈ（Ｃ１，３５）を受信したセンサアダプタアプリ７０２＃３は、携帯端末１０２＃Ｂが有する温度センサにアクセスしようとする。しかし、携帯端末１０２＃Ｂは移動しており、センサアダプタアプリ７０２＃３は、携帯端末１０２＃Ｂが有する温度センサにアクセスすることはできない。センサアダプタアプリ７０２＃３は、予め指定された回数だけリトライした後、図１７に示す（６）の処理において、Ｐｕｂ／Ｓｕｂサーバアプリ７０１＃１に、ｎａｃｋを通知する。

ｎａｃｋを受信したＰｕｂ／Ｓｕｂサーバアプリ７０１＃１は、第２のＰｕｂｌｉｓｈ処理の一部として、図１７に示す（７）の処理により、Ｐｕｂ／Ｓｕｂサーバアプリ７０１＃１は、ｎａｃｋによる再送待ちの数と、新たに届いたＳｕｂｓｃｒｉｂｅの数とを比較する。図１７の例では、ｎａｃｋによる再送待ちの数が１であり、新たに届いたＳｕｂｓｃｒｉｂｅの数が１であるため、一致することになる。従って、この場合、Ｐｕｂ／Ｓｕｂサーバアプリ７０１＃１は、ｎａｃｋによる再送待ちを削除する。

次に、第２のＰｕｂｌｉｓｈ処理を示すフローチャートを、図１８を用いて説明する。なお、ＣＣＮ１０１からのＳｕｂｓｃｒｉｂｅ受信時処理を示すフローチャートについては、図１６で示したものと同一となるため、説明を省略する。

図１８は、第２のＰｕｂｌｉｓｈ処理手順の一例を示すフローチャートである。第２のＰｕｂｌｉｓｈ処理は、Ｐｕｂ／Ｓｕｂサーバアプリ７０１が行う処理であり、Ｐｕｂｌｉｓｈを送信する処理である。

Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、Ｐｕｂｌｉｓｈ処理の起動理由を確認する（ステップＳ１８０１）。新規Ｐｕｂｌｉｓｈを受信したことによりＰｕｂｌｉｓｈ処理を起動した場合（ステップＳ１８０１：新規Ｐｕｂｌｉｓｈ受信）、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、ＴｏｐｉｃをキーにＳｕｂｓｃｒｉｂｅｒリスト８１１を検索する（ステップＳ１８０２）。そして、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、Ｓｕｂｓｃｒｉｂｅｒリスト８１１から、キーとしたＴｏｐｉｃに対応したＳｕｂｓｃｒｉｂｅｒＩＰの一覧を取得する（ステップＳ１８０３）。

一方、再送のため定期起動によりＰｕｂｌｉｓｈ処理を起動した場合（ステップＳ１８０１：定期起動）、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、再送信待ちリスト８１３を参照して、ＳｕｂｓｃｒｉｂｅｒＩＰの一覧を取得する（ステップＳ１８０４）。

ステップＳ１８０３、ステップＳ１８０４のうちのいずれか一方の処理終了後、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、ＳｕｂｓｃｒｉｂｅｒＩＰの一覧に含まれるＳｕｂｓｃｒｉｂｅｒのそれぞれに対し、Ｐｕｂｌｉｓｈを通知する（ステップＳ１８０５）。次に、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、Ｐｕｂｌｉｓｈに対するｎａｃｋを受信したか否かを判断する（ステップＳ１８０６）。Ｐｕｂｌｉｓｈに対するｎａｃｋを受信した場合（ステップＳ１８０６：Ｙｅｓ）、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、受信したｎａｃｋに対するＰｕｂｌｉｓｈを、再送信待ちリスト８１３に登録する（ステップＳ１８０７）。そして、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、再送信待ちリスト８１３から、Ｔｏｐｉｃに対するエントリ数を計数する（ステップＳ１８０８）。

次に、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、ＣＣＮ−Ｓｕｂｓｃｒｉｂｅ数と再送信待ちリスト８１３のエントリ数とが同一のＴｏｐｉｃがあるか否かを判断する（ステップＳ１８０９）。ＣＣＮ−Ｓｕｂｓｃｒｉｂｅ数と再送信待ちリスト８１３のエントリ数とが同一のＴｏｐｉｃがある場合（ステップＳ１８０９：Ｙｅｓ）、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、再送信待ちリスト８１３のＳｕｂｓｃｒｉｂｅｒＩＰにあるノードを、Ｓｕｂｓｃｒｉｂｅｒリスト８１１から削除する（ステップＳ１８１０）。そして、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、ＣＣＮ−Ｓｕｂｓｃｒｉｂｅ数リスト８１２および再送信待ちリスト８１３から、数が同一のＴｏｐｉｃを有するエントリを削除する（ステップＳ１８１１）。そして、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、第２のＰｕｂｌｉｓｈ処理を終了する。

また、Ｐｕｂｌｉｓｈに対するｎａｃｋを受信していない場合（ステップＳ１８０６：Ｎｏ）、またはＣＣＮ−Ｓｕｂｓｃｒｉｂｅ数と再送信待ちリスト８１３のエントリ数とが同一のＴｏｐｉｃがない場合（ステップＳ１８０９：Ｎｏ）、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、第２のＰｕｂｌｉｓｈ処理を終了する。

第２のＰｕｂｌｉｓｈ処理を実行することにより、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、Ｔｏｐｉｃに登録しているＳｕｂｓｃｒｉｂｅｒへＴｏｐｉｃが示す情報を通知することができる。さらに、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、Ｐｕｂｌｉｓｈの前にＳｕｂｓｃｒｉｂｅが通知されても、ＣＣＮ−ｓｕｂｓｃｒｉｂｅ数と再送信待ちリスト８１３のエントリ数とが同一であれば、ｎａｃｋによる再送を抑制することができる。

（Ｅｘｐｉｒｅ時刻が到来した場合）
次に、図１９〜図２１を用いて、Ｅｘｐｉｒｅ時刻が到来した場合に、携帯端末１０２が移動することにより発生するＰｕｂｌｉｓｈの再送を抑制する例を説明する。

図１９は、Ｅｘｐｉｒｅ時刻到来時の各リストの記憶内容の一例を示す説明図（その１）である。また、図２０は、Ｅｘｐｉｒｅ時刻到来時の各リストの記憶内容の一例を示す説明図（その２）である。図１９、図２０では、ＣＣＮ１０１＃１におけるＳｕｂｓｃｒｉｂｅｒリスト８１１＃１、ＣＣＮ−Ｓｕｂｓｃｒｉｂｅ数リスト８１２＃１、再送信待ちリスト８１３＃１の記憶内容を用いて説明を行う。

図１９に示す状態１９０１では、図５で示した状態から、さらに、ＣＣＮ１０１＃５の配下の位置に、携帯端末１０２＃Ｃがあるとする。また、ＣＣＮ１０１＃５および携帯端末１０２＃Ｃには、図１９で示す条件情報Ｃ３が登録されている。条件情報Ｃ３の内容は、「Ｉｆ ＣＣＮ１０１＃１からＣ１が成立したことを受信 ＡＮＤ 携帯端末１０２＃Ｃの温度＜２５度 Ｔｈｅｎ 通知（サービス利用者、携帯端末１０２＃Ｃの温度）」である。この状態で、Ｓｕｂｓｃｒｉｂｅｒリスト８１１＃１は、状態１９０１の枠内で示したように、エントリ１９１１−１〜３を有する。

状態１９０１から携帯端末１０２＃Ｂが離脱した後、Ｐｕｂ／Ｓｕｂサーバアプリ７０１＃１が、センサアダプタアプリ７０２＃１からＰｕｂｌｉｓｈ（Ｃ１，３５）を受信したとする。この場合、Ｐｕｂ／Ｓｕｂサーバアプリ７０１＃１は、Ｓｕｂｓｃｒｉｂｅｒリスト８１１＃１を参照して、通知先としてＣＣＮ１０１＃３、５を得る。そして、Ｐｕｂ／Ｓｕｂサーバアプリ７０１＃１は、通知先となるＣＣＮ１０１＃３、５にＰｕｂｌｉｓｈ（Ｃ１，３５）を通知する。Ｐｕｂｌｉｓｈ（Ｃ１，３５）を受信したＣＣＮ１０１＃３は、条件情報Ｃ２に従って、携帯端末１０２＃Ｂにアクセスしようとするが、携帯端末１０２＃２が離脱しているためアクセスできない。従って、ＣＣＮ１０１＃３は、ｎａｃｋをＣＣＮ１０１＃１に送信する。

ＣＣＮ１０１＃３からのｎａｃｋをＣＣＮ１０１＃１が受信して、ｎａｃｋに対するＰｕｂｌｉｓｈを再送信待ちリスト８１３＃１を登録した状態が、図１９に示す状態１９０２である。この状態で、再送信待ちリスト８１３＃１は、状態１９０２の枠内で示したように、エントリ１９１２−１を有する。

状態１９０２から携帯端末１０２＃Ｃが離脱した後、Ｐｕｂ／Ｓｕｂサーバアプリ７０１＃１が、センサアダプタアプリ７０２＃１からＰｕｂｌｉｓｈ（Ｃ１，３５）を受信したとする。この場合、Ｐｕｂ／Ｓｕｂサーバアプリ７０１＃１は、Ｓｕｂｓｃｒｉｂｅｒリスト８１１＃１を参照して、通知先としてＣＣＮ１０１＃３、５を得る。しかしながら、ＣＣＮ１０１＃３は再送信待ちリスト８１３に登録されているため、Ｐｕｂ／Ｓｕｂサーバアプリ７０１＃１は、ＣＣＮ１０１＃５に、Ｐｕｂｌｉｓｈ（Ｃ１，３５）を通知する。Ｐｕｂｌｉｓｈ（Ｃ１，３５）を受信したＣＣＮ１０１＃５は、条件情報Ｃ３に従って、携帯端末１０２＃Ｃにアクセスしようとするが、携帯端末１０２＃Ｃが離脱しているためアクセスできない。従って、ＣＣＮ１０１＃５は、ｎａｃｋをＣＣＮ１０１＃１に送信する。

ＣＣＮ１０１＃５からのｎａｃｋをＣＣＮ１０１＃１が受信して、ｎａｃｋに対するＰｕｂｌｉｓｈを再送信待ちリスト８１３＃１を登録した状態が、図１９に示す状態１９０３である。この状態で、再送信待ちリスト８１３＃１は、状態１９０３の枠内で示したように、エントリ１９１２−１、２を有する。

状態１９０３から、携帯端末１０２＃ＢがＣＣＮ１０１＃４の領域に到着したとする。この場合、ＣＣＮ１０１＃４は、Ｒｅｇｉｓｔｅｒおよび条件設定要求を携帯端末１０２＃Ｂから受信する。そして、ＣＣＮ１０１＃４は、条件情報Ｃ２に基づいて、ＳｕｂｓｃｒｉｂｅをＣＣＮ１０１＃１に送信する。

ＣＣＮ１０１＃１からのＳｕｂｓｃｒｉｂｅを受信してＳｕｂｓｃｒｉｂｅｒリスト８１１＃１と、ＣＣＮ−Ｓｕｂｓｃｒｉｂｅ数リスト８１２＃１とを更新した状態が、図１９に示す状態１９０４である。この状態で、Ｓｕｂｓｃｒｉｂｅｒリスト８１１＃１は、状態１９０４の枠内で示したように、エントリ１９１１−４が追加されて、エントリ１９１１−１〜４を有する。同様に、ＣＣＮ−Ｓｕｂｓｃｒｉｂｅ数リスト８１２＃１は、エントリ１９１３−１を有する。

また、状態１９０４においてＰｕｂ／Ｓｕｂサーバアプリ７０１＃１は、再送信待ちリスト８１３＃１とＣＣＮ−Ｓｕｂｓｃｒｉｂｅ数リスト８１２＃１とについて、Ｔｏｐｉｃごとの数を確認し、一致するか否かを判断する。この場合、条件情報Ｃ１について、再送信待ちリスト８１３＃１には、２エントリあり、ＣＣＮ−Ｓｕｂｓｃｒｉｂｅ数リスト８１２＃１には１エントリあり、数が異なる。従って、Ｐｕｂ／Ｓｕｂサーバアプリ７０１＃１は、何もせず次の処理に進む。

状態１９０４から、携帯端末１０２がどのＣＣＮ１０１にも登録せず、エントリ１９１２−１のＥｘｐｉｒｅ時刻が到来したとする。この場合、Ｐｕｂ／Ｓｕｂサーバアプリ７０１＃１は、Ｅｘｐｉｒｅ時刻到来時処理として、再送信待ちリスト８１３＃１からＥｘｐｉｒｅ時刻が到来したエントリ１９１２−１を削除する。合わせて、Ｐｕｂ／Ｓｕｂサーバアプリ７０１＃１は、Ｓｕｂｓｃｒｉｂｅｒリスト８１１＃１から、エントリ１９１１−１を削除する。また、Ｅｘｐｉｒｅ時刻到来時処理については、図２１で示す。２つのエントリを削除した状態が、図２０で示す状態２００１である。

２つのエントリを削除した後、Ｐｕｂ／Ｓｕｂサーバアプリ７０１＃１は、再送信待ちリスト８１３＃１とＣＣＮ−Ｓｕｂｓｃｒｉｂｅ数リスト８１２＃１とについてＴｏｐｉｃごとの数を確認し、一致するか否かを判断する。この場合、条件情報Ｃ１について、再送信待ちリスト８１３＃１、ＣＣＮ−Ｓｕｂｓｃｒｉｂｅ数リスト８１２＃１ともに１エントリであり、数が一致する。従って、Ｐｕｂ／Ｓｕｂサーバアプリ７０１＃１は、再送信待ちリスト８１３＃１から、数が一致したＴｏｐｉｃであるエントリ１９１２−２を削除する。合わせて、Ｐｕｂ／Ｓｕｂサーバアプリ７０１＃１は、Ｓｕｂｓｃｒｉｂｅｒリスト８１１＃１から、エントリ１９１１−３を削除する。２つのエントリを削除した状態が、図２０で示す状態２００２である。このように、Ｐｕｂ／Ｓｕｂサーバアプリ７０１＃１は、ｎａｃｋによる再送を停止することが可能になる。

次に、Ｅｘｐｉｒｅ時刻到来時処理を示すフローチャートを、図２１を用いて説明する。

図２１は、Ｅｘｐｉｒｅ時刻到来時処理手順の一例を示すフローチャートである。Ｅｘｐｉｒｅ時刻到来時処理は、Ｅｘｐｉｒｅ時刻が到来する際に行う処理である。

Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、再送信待ちリスト８１３からＥｘｐｉｒｅ時刻が到来したエントリと、Ｓｕｂｓｃｒｉｂｅｒリスト８１１から当該ＳｕｂｓｃｒｉｂｅｒＩＰのエントリを削除する（ステップＳ２１０１）。次に、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、ＣＣＮ−Ｓｕｂｓｃｒｉｂｅ数と再送信待ちリスト８１３のエントリ数とが同一のＴｏｐｉｃがあるか否かを判断する（ステップＳ２１０２）。ＣＣＮ−Ｓｕｂｓｃｒｉｂｅ数と再送信待ちリスト８１３のエントリ数とが同一のＴｏｐｉｃがある場合（ステップＳ２１０２：Ｙｅｓ）、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、再送信待ちリスト８１３から、数が同一のＴｏｐｉｃを有するエントリを削除する（ステップＳ２１０３）。続けて、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、Ｓｕｂｓｃｒｉｂｅｒリスト８１１から、再送信待ちリスト８１３から削除したエントリに対応するエントリを削除する（ステップＳ２１０４）。

ステップＳ２１０４の処理終了後、または、ＣＣＮ−Ｓｕｂｓｃｒｉｂｅ数と再送信待ちリスト８１３のエントリ数とが同一のＴｏｐｉｃがない場合（ステップＳ２１０２：Ｎｏ）、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、Ｅｘｐｉｒｅ時刻到来時処理を終了する。Ｅｘｐｉｒｅ時刻到来時処理を実行することにより、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、Ｅｘｐｉｒｅ時刻が到来してエントリを削除する。そして、Ｐｕｂ／Ｓｕｂサーバアプリ７０１は、エントリを削除したことにより、ＣＣＮ−ｓｕｂｓｃｒｉｂｅ数と再送信待ちリスト８１３のエントリ数とが同一になれば、数が一致したエントリを削除して、ｎａｃｋによる再送を抑制することができる。

以上説明したように、分散制御システム１００によれば、あるＴｏｐｉｃのｎａｃｋをＣＣＮ１０１＃３から受信し、あるＴｏｐｉｃのＳｕｂｓｃｒｉｂｅをＣＣＮ１０１＃５から受信したら、あるＴｏｐｉｃのＳｕｂｓｃｒｉｂｅｒをＣＣＮ１０１＃５に変更する。これにより、分散制御システム１００は、携帯端末１０２＃Ｂの移動を認識することができ、分散処理を継続させることができる。

また、分散制御システム１００によれば、Ｐｕｂｌｉｓｈの後にＳｕｂｓｃｒｉｂｅが通知される場合、Ｔｏｐｉｃごとに、再送信待ちリスト８１３に含まれるＣＣＮ１０１の数と、Ｓｕｂｓｃｒｉｂｅを送信したＣＣＮ１０１の数とが一致するか判断してもよい。これにより、分散制御システム１００は、Ｐｕｂｌｉｓｈの後にＳｕｂｓｃｒｉｂｅが通知される場合でも、ｎａｃｋによる再送を停止させることが可能になる。

また、分散制御システム１００によれば、Ｐｕｂｌｉｓｈの前にＳｕｂｓｃｒｉｂｅが通知される場合、Ｔｏｐｉｃごとに、再送信待ちリスト８１３に含まれるＣＣＮ１０１の数と、Ｓｕｂｓｃｒｉｂｅを送信したＣＣＮ１０１の数とが一致するか判断してもよい。これにより、分散制御システム１００は、Ｐｕｂｌｉｓｈの前にＳｕｂｓｃｒｉｂｅが通知される場合でも、ｎａｃｋによる再送を停止させることが可能になる。

また、分散制御システム１００によれば、Ｅｘｐｉｒｅ時刻が到来した場合に、Ｔｏｐｉｃごとに、再送信待ちリスト８１３に含まれるＣＣＮ１０１の数と、Ｓｕｂｓｃｒｉｂｅを送信したＣＣＮ１０１の数とが一致するか判断してもよい。これにより、分散制御システム１００は、Ｅｘｐｉｒｅ時刻が到来した際に、ｎａｃｋによる再送を停止させることが可能になる。

そして、ｎａｃｋによる再送を停止させることにより、ネットワークにかかるコストや、センサアダプタアプリ７０２の処理を削減することができる。例えば、再送を行う回数の上限が１０回であるとすると、かかるコストは最大で１／１０以下となる。また、本実施の形態にかかる方法は、移動先のセンサアダプタアプリが、移動元のセンサアダプタアプリに伝えるようにする方法に比べて、実施コストも低くなる。

なお、本実施の形態で説明した分散制御方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本分散制御プログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ−Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また本分散制御プログラムは、インターネット等のネットワークを介して配布してもよい。

上述した実施の形態に関し、さらに以下の付記を開示する。

（付記１）それぞれ異なる位置に配置された複数の通知装置と、前記複数の通知装置のうちの自装置の位置に応じた通知装置に事象の検出を通知する検出装置とを含む分散制御システムにおける分散制御方法であって、
第１の事象を検出する検出装置に接続した第１の通知装置が、
前記第１の事象を検出する検出装置から前記第１の事象の検出を受信した場合、第２の事象を検出する検出装置に接続した第２の通知装置の識別情報と前記第１の事象の識別情報とを対応付けた通知先情報を参照して、前記第１の事象の検出を前記第２の通知装置に通知し、
前記第２の通知装置から前記第１の事象の検出に応じた処理を実行することができない旨の否定応答を受信した場合、前記第１の事象の識別情報と前記第２の通知装置の識別情報とを対応付けて否定応答情報に格納し、
前記第２の事象を検出する検出装置に接続した第３の通知装置から前記第１の事象の検出の通知の依頼を受信したことに応じて、前記否定応答情報に前記第１の事象の識別情報が含まれるか否かを判断し、
前記否定応答情報に前記第１の事象の識別情報が含まれると判断した場合、前記通知先情報と前記否定応答情報とから、前記第１の事象の識別情報に対応付けられた前記第２の通知装置の識別情報を削除する、
処理を実行することを特徴とする分散制御方法。

（付記２）前記判断する処理は、
前記否定応答を受信した後に前記第３の通知装置から前記依頼を受信したことに応じて、前記否定応答情報に含まれる前記第１の事象の識別情報に対応付けられた通知装置の識別情報の数と、前記依頼を送信した通知装置の数とが一致するか否かを判断し、
前記削除する処理は、
前記否定応答情報に含まれる前記第１の事象の識別情報に対応付けられた通知装置の識別情報の数と前記依頼を送信した通知装置の数とが一致すると判断した場合、前記通知先情報と前記否定応答情報とから、前記第１の事象の識別情報に対応付けられた前記第２の通知装置の識別情報を削除する、
ことを特徴とする付記１に記載の分散制御方法。

（付記３）前記通知する処理は、
前記否定応答を受信する前に前記第３の通知装置から前記依頼を受信した後に、前記第１の事象を検出する検出装置から前記第１の事象の検出を受信した場合、さらに、前記第１の事象の検出を前記第３の通知装置に通知し、
前記判断する処理は、
前記否定応答を受信したことに応じて、前記否定応答情報に含まれる前記第１の事象の識別情報に対応付けられた通知装置の識別情報の数と、前記依頼を送信した通知装置の数とが一致するか否かを判断し、
前記削除する処理は、
前記否定応答情報に含まれる前記第１の事象の識別情報に対応付けられた通知装置の識別情報の数と前記依頼を送信した通知装置の数とが一致すると判断した場合、前記通知先情報と前記否定応答情報とから、前記第１の事象の識別情報に対応付けられた前記第２の通知装置の識別情報を削除する、
ことを特徴とする付記１または２に記載の分散制御方法。

（付記４）前記格納する処理は、
前記否定応答を受信した場合、前記第１の事象の識別情報と前記第２の通知装置の識別情報と前記否定応答を受信した時刻に基づいた期限時刻を示す値とを対応付けて前記否定応答情報に格納し、
前記判断する処理は、
現在時刻が前記期限時刻となったことに応じて、前記否定応答情報に含まれる前記第１の事象の識別情報に対応付けられた通知装置の識別情報の数と、前記依頼を送信した通知装置の数とが一致するか否かを判断し、
前記削除する処理は、
前記否定応答情報に含まれる前記第１の事象の識別情報に対応付けられた通知装置の識別情報の数と前記依頼を送信した通知装置の数とが一致すると判断した場合、前記通知先情報と前記否定応答情報とから、前記第１の事象の識別情報に対応付けられた前記第２の通知装置の識別情報を削除する、
ことを特徴とする付記１〜３のいずれか一つに記載の分散制御方法。

（付記５）それぞれ異なる位置に配置された複数の通知装置と、前記複数の通知装置のうちの自装置の位置に応じた通知装置に事象の検出を通知する検出装置とを含む分散制御システムであって、
第１の事象を検出する検出装置に接続した第１の通知装置は、
前記第１の事象を検出する検出装置から前記第１の事象の検出を受信した場合、第２の事象を検出する検出装置に接続した第２の通知装置の識別情報と前記第１の事象の識別情報とを対応付けた通知先情報を参照して、前記第１の事象の検出を前記第２の通知装置に通知し、
前記第２の通知装置から前記第１の事象の検出に応じた処理を実行することができない旨の否定応答を受信した場合、前記第１の事象の識別情報と前記第２の通知装置の識別情報とを対応付けて否定応答情報に格納し、
前記第２の事象を検出する検出装置に接続した第３の通知装置から前記第１の事象の検出の通知の依頼を受信したことに応じて、前記否定応答情報に前記第１の事象の識別情報が含まれるか否かを判断し、
前記否定応答情報に前記第１の事象の識別情報が含まれると判断した場合、前記通知先情報と前記否定応答情報とから、前記第１の事象の識別情報に対応付けられた前記第２の通知装置の識別情報を削除する、
ことを特徴とする分散制御システム。

（付記６）それぞれ異なる位置に配置された複数の通知装置と、前記複数の通知装置のうちの自装置の位置に応じた通知装置に事象の検出を通知する検出装置とを含む分散制御システムにおける分散制御プログラムであって、
第１の事象を検出する検出装置に接続した第１の通知装置に、
前記第１の事象を検出する検出装置から前記第１の事象の検出を受信した場合、第２の事象を検出する検出装置に接続した第２の通知装置の識別情報と前記第１の事象の識別情報とを対応付けた通知先情報を参照して、前記第１の事象の検出を前記第２の通知装置に通知し、
前記第２の通知装置から前記第１の事象の検出に応じた処理を実行することができない旨の否定応答を受信した場合、前記第１の事象の識別情報と前記第２の通知装置の識別情報とを対応付けて否定応答情報に格納し、
前記第２の事象を検出する検出装置に接続した第３の通知装置から前記第１の事象の検出の通知の依頼を受信したことに応じて、前記否定応答情報に前記第１の事象の識別情報が含まれるか否かを判断し、
前記否定応答情報に前記第１の事象の識別情報が含まれると判断した場合、前記通知先情報と前記否定応答情報とから、前記第１の事象の識別情報に対応付けられた前記第２の通知装置の識別情報を削除する、
処理を実行させることを特徴とする分散制御プログラム。

（付記７）それぞれ異なる位置に配置された複数の通知装置のうちのいずれかの事象を検出する検出装置に接続したいずれかの通知装置に、
前記複数の通知装置のうちの前記いずれかの通知装置とは異なる他の通知装置から前記いずれかの事象とは異なる他の事象の検出を受信した場合、前記他の通知装置から前記他の事象の検出を受信し、かつ、前記いずれかの事象を検出したかを示す条件と前記条件を満たす際の所定の処理とを示す条件情報を参照して、前記いずれかの事象を検出する検出装置に前記いずれかの事象の検出の有無の送信要求を送信し、
前記送信要求に対する応答がない場合、前記他の事象の検出に対応する処理を実行することができない旨の否定応答を前記他の通知装置に送信する、
処理を実行させることを特徴とする分割制御プログラム。

（付記８）それぞれ異なる位置に配置された複数の通知装置のうちのいずれかの事象を検出する検出装置に接続したいずれかの通知装置に、
前記複数の通知装置のうちの前記いずれかの通知装置とは異なる他の通知装置から前記いずれかの事象とは異なる他の事象の検出を受信し、かつ、前記いずれかの事象を検出したかを示す条件と前記条件を満たす際の所定の処理とを示す条件情報を記憶しており前記いずれかの事象を検出する検出装置と接続して前記検出装置から前記条件情報を受信した場合、前記他の事象の検出の通知の依頼を前記他の通知装置に送信し、
前記他の事象の検出を前記他の通知装置から受信した場合、前記条件情報を参照して、前記いずれかの事象を検出する検出装置に前記いずれかの事象の検出の有無の送信要求を送信し、
前記いずれかの事象を検出する検出装置から前記いずれかの事象の検出を受信した場合、前記条件情報を参照して前記所定の処理を実行する、
処理を実行させることを特徴とする分割制御プログラム。

１００ 分散制御システム
１０１ ＣＣＮ
１０２ 携帯端末
１０３ 温度センサ
８００ 制御部
８０１ 通知部
８０２ 格納部
８０３ 判断部
８０４ 削除部
８０５ 送信部
８０６ 実行部
８１１ Ｓｕｂｓｃｒｉｂｅｒリスト
８１２ ＣＣＮ−Ｓｕｂｓｃｒｉｂｅ数リスト
８１３ 再送信待ちリスト

Claims (6)

1. それぞれ異なる位置に配置された複数の通知装置と、前記複数の通知装置のうちの自装置の位置に応じた通知装置に事象の検出を通知する検出装置とを含む分散制御システムにおける分散制御方法であって、
   第１の事象を検出する検出装置に接続した第１の通知装置が、
   前記第１の事象を検出する検出装置から前記第１の事象の検出を受信した場合、前記第１の事象の識別情報と、前記第１の事象の検出の通知を依頼する通知装置の識別情報とを対応付けた通知先情報を参照して、前記第１の事象の識別情報に対応付けられた識別情報の第２の通知装置に、前記第１の事象の検出を通知し、
   前記第２の通知装置から前記第１の事象の検出に応じた処理を実行することができない旨の否定応答を受信した場合、前記第１の事象の識別情報と前記第２の通知装置の識別情報とを対応付けて否定応答情報に格納し、
   第２の事象を検出する第２の検出装置が前記第２の通知装置の配下の位置から第３の通知装置の配下の位置に移動した際に前記第２の検出装置から前記第３の通知装置に通知される条件情報に、前記第１の通知装置の識別情報が含まれる場合に前記第３の通知装置から通知される、前記第１の事象の検出の通知の依頼を受信したことに応じて、前記否定応答情報に前記第１の事象の識別情報が含まれるか否かを判断し、
   前記否定応答情報に前記第１の事象の識別情報が含まれると判断した場合、前記通知先情報と前記否定応答情報とから、前記第１の事象の識別情報に対応付けられた前記第２の通知装置の識別情報を削除する、
   処理を実行することを特徴とする分散制御方法。
2. 前記判断する処理は、
   前記否定応答を受信した後に前記第３の通知装置から前記依頼を受信したことに応じて、前記否定応答情報に含まれる前記第１の事象の識別情報に対応付けられた通知装置の識別情報の数と、前記依頼を送信した通知装置の数とが一致するか否かを判断し、
   前記削除する処理は、
   前記否定応答情報に含まれる前記第１の事象の識別情報に対応付けられた通知装置の識別情報の数と前記依頼を送信した通知装置の数とが一致すると判断した場合、前記通知先情報と前記否定応答情報とから、前記第１の事象の識別情報に対応付けられた前記第２の通知装置の識別情報を削除する、
   ことを特徴とする請求項１に記載の分散制御方法。
3. 前記通知する処理は、
   前記否定応答を受信する前に前記第３の通知装置から前記依頼を受信した後に、前記第１の事象を検出する検出装置から前記第１の事象の検出を受信した場合、さらに、前記第１の事象の検出を前記第３の通知装置に通知し、
   前記判断する処理は、
   前記否定応答を受信したことに応じて、前記否定応答情報に含まれる前記第１の事象の識別情報に対応付けられた通知装置の識別情報の数と、前記依頼を送信した通知装置の数とが一致するか否かを判断し、
   前記削除する処理は、
   前記否定応答情報に含まれる前記第１の事象の識別情報に対応付けられた通知装置の識別情報の数と前記依頼を送信した通知装置の数とが一致すると判断した場合、前記通知先情報と前記否定応答情報とから、前記第１の事象の識別情報に対応付けられた前記第２の通知装置の識別情報を削除する、
   ことを特徴とする請求項１または２に記載の分散制御方法。
4. 前記格納する処理は、
   前記否定応答を受信した場合、前記第１の事象の識別情報と前記第２の通知装置の識別情報と前記否定応答を受信した時刻に基づいた期限時刻を示す値とを対応付けて前記否定応答情報に格納し、
   前記判断する処理は、
   現在時刻が前記期限時刻となったことに応じて、前記否定応答情報に含まれる前記第１の事象の識別情報に対応付けられた通知装置の識別情報の数と、前記依頼を送信した通知装置の数とが一致するか否かを判断し、
   前記削除する処理は、
   前記否定応答情報に含まれる前記第１の事象の識別情報に対応付けられた通知装置の識別情報の数と前記依頼を送信した通知装置の数とが一致すると判断した場合、前記通知先情報と前記否定応答情報とから、前記第１の事象の識別情報に対応付けられた前記第２の通知装置の識別情報を削除する、
   ことを特徴とする請求項１〜３のいずれか一つに記載の分散制御方法。
5. それぞれ異なる位置に配置された複数の通知装置と、前記複数の通知装置のうちの自装置の位置に応じた通知装置に事象の検出を通知する検出装置とを含む分散制御システムであって、
   第１の事象を検出する検出装置に接続した第１の通知装置は、
   前記第１の事象を検出する検出装置から前記第１の事象の検出を受信した場合、前記第１の事象の識別情報と、前記第１の事象の検出の通知を依頼する通知装置の識別情報とを対応付けた通知先情報を参照して、前記第１の事象の識別情報に対応付けられた識別情報の第２の通知装置に、前記第１の事象の検出を通知し、
   前記第２の通知装置から前記第１の事象の検出に応じた処理を実行することができない旨の否定応答を受信した場合、前記第１の事象の識別情報と前記第２の通知装置の識別情報とを対応付けて否定応答情報に格納し、
   第２の事象を検出する第２の検出装置が前記第２の通知装置の配下の位置から第３の通知装置の配下の位置に移動した際に前記第２の検出装置から前記第３の通知装置に通知される条件情報に、前記第１の通知装置の識別情報が含まれる場合に前記第３の通知装置から通知される、前記第１の事象の検出の通知の依頼を受信したことに応じて、前記否定応答情報に前記第１の事象の識別情報が含まれるか否かを判断し、
   前記否定応答情報に前記第１の事象の識別情報が含まれると判断した場合、前記通知先情報と前記否定応答情報とから、前記第１の事象の識別情報に対応付けられた前記第２の通知装置の識別情報を削除する、
   ことを特徴とする分散制御システム。
6. それぞれ異なる位置に配置された複数の通知装置と、前記複数の通知装置のうちの自装置の位置に応じた通知装置に事象の検出を通知する検出装置とを含む分散制御システムにおける分散制御プログラムであって、
   第１の事象を検出する検出装置に接続した第１の通知装置に、
   前記第１の事象を検出する検出装置から前記第１の事象の検出を受信した場合、前記第１の事象の識別情報と、前記第１の事象の検出の通知を依頼する通知装置の識別情報とを対応付けた通知先情報を参照して、前記第１の事象の識別情報に対応付けられた識別情報の第２の通知装置に、前記第１の事象の検出を通知し、
   前記第２の通知装置から前記第１の事象の検出に応じた処理を実行することができない旨の否定応答を受信した場合、前記第１の事象の識別情報と前記第２の通知装置の識別情報とを対応付けて否定応答情報に格納し、
   第２の事象を検出する第２の検出装置が前記第２の通知装置の配下の位置から第３の通知装置の配下の位置に移動した際に前記第２の検出装置から前記第３の通知装置に通知される条件情報に、前記第１の通知装置の識別情報が含まれる場合に前記第３の通知装置から通知される、前記第１の事象の検出の通知の依頼を受信したことに応じて、前記否定応答情報に前記第１の事象の識別情報が含まれるか否かを判断し、
   前記否定応答情報に前記第１の事象の識別情報が含まれると判断した場合、前記通知先情報と前記否定応答情報とから、前記第１の事象の識別情報に対応付けられた前記第２の通知装置の識別情報を削除する、
   処理を実行させることを特徴とする分散制御プログラム。

Images