[go: up one dir, main page]

JP5269619B2 - 外部装置を監視する装置、方法およびプログラム - Google Patents

外部装置を監視する装置、方法およびプログラム Download PDF

Info

Publication number
JP5269619B2
JP5269619B2 JP2009001120A JP2009001120A JP5269619B2 JP 5269619 B2 JP5269619 B2 JP 5269619B2 JP 2009001120 A JP2009001120 A JP 2009001120A JP 2009001120 A JP2009001120 A JP 2009001120A JP 5269619 B2 JP5269619 B2 JP 5269619B2
Authority
JP
Japan
Prior art keywords
external device
unit
confirmation request
communication
transmission
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2009001120A
Other languages
English (en)
Other versions
JP2010161507A (ja
Inventor
雄 金子
雅彰 内田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toshiba Corp filed Critical Toshiba Corp
Priority to JP2009001120A priority Critical patent/JP5269619B2/ja
Publication of JP2010161507A publication Critical patent/JP2010161507A/ja
Application granted granted Critical
Publication of JP5269619B2 publication Critical patent/JP5269619B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Small-Scale Networks (AREA)

Description

この発明は、ネットワークを介して接続された他のデバイス(外部装置)を監視する装置、方法およびプログラムに関する。
近年、大型のビルには、空調や照明などの設備機器を、ネットワークを介して監視制御するためのビル監視制御システムが導入されている。多くのビル監視制御システムで使われている通信プロトコルとして、BACnetプロトコルが存在する。BACnetプロトコルを使った監視制御システムでは、監視サーバやローカルコントロールサーバ(LCS)などのデバイスがBACnetプロトコルに基づいて通信することで監視制御を実現する。電気設備学会が発行した非特許文献1は、BACnetプロトコルを使用するシステムにおけるデバイスの相互接続のための標準機能を提案している。各ベンダがこの標準機能を実装することで、複数のベンダのデバイスが混在する場合でも、監視制御システムは正常に動作することができる。
非特許文献1では、標準機能の1つとして、デバイスのアライブチェック機能が提案されている。アライブチェック機能とは、監視制御システムに接続されている他のデバイスが正常な状態か否かを把握するための機能である。各ベンダが非特許文献1に基づいてアライブチェック機能を実装することで、複数のベンダのデバイスが混在する環境でも、アライブチェックを正しく行うことができる。
非特許文献1で提案されているアライブチェック機能では、3つの機能が定義されている。1つ目の機能はWho−Is送信機能である。このWho−Is送信機能を備えるデバイスは、BACnetプロトコルで定義されるWho−Isメッセージ(以下、単にWho−isという場合がある)を一定周期(非特許文献1による推奨周期は60秒)でブロードキャストする。以下、Who−Is送信機能を実行するデバイスのことをWho−Is送信デバイスと呼ぶ。
2つ目の機能はWho−Is監視機能である。このWho−Is監視機能を備えるデバイスは、Who−Is送信デバイスがブロードキャストするWho−Isを監視する。そして、一定時間(非特許文献1による推奨時間は90秒)以上、Who−Isが送信されていない場合には、Who−Is送信デバイスに代わり、Who−Is送信を開始する。以下、Who−Is監視機能を実行するデバイスのことをWho−Is監視デバイスと呼ぶ。
3つ目の機能はI−Am監視機能である。BACnetプロトコルでは、Who−Isを受信したデバイスは、応答としてI−Amメッセージ(以下、単にI−Amという場合がある)をブロードキャストする。このI−Am監視機能を備えるデバイスは、Who−Isに対して各デバイスがブロードキャストするI−Amを監視する。そして、一定時間(非特許文献1による推奨時間は150秒)以上、I−Amを送信しないデバイスを異常であると判定する。
IEIEJ−G−0006:2006 BACnetシステム インターオペラビリティガイドライン
各デバイスの処理負荷の増加や、ネットワーク帯域の圧迫を避けるためには、Who−Is送信デバイスは1台のみであることが望ましい。一方、Who−Is送信デバイスが異常終了した際にも、監視制御システムでアライブチェック機能が継続実行されるためには、Who−Is監視デバイスが複数存在することが望ましい。
しかしながら、非特許文献1で提案されている方法では、Who−Is送信デバイスが異常終了し、かつ、Who−Is監視デバイスが複数存在した場合に、いずれのWho−Is監視デバイスがWho−Is送信を代行実行すべきかを一意に定めることができなかった。したがって、前回のWho−Isが送信されてから90秒経過した時点で、複数のWho−Is監視デバイスが一斉にWho−Isをブロードキャストし、各デバイスの処理負荷の増大やネットワーク帯域の圧迫を引き起こすという問題があった。
本発明は、上記に鑑みてなされたものであって、他の装置を監視するためのメッセージを送信する装置に異常が発生した時に、当該メッセージの送信を代行する装置を適切に定めることにより、処理負荷の増大を回避することができる装置、方法およびプログラムを提供することを目的とする。
上述した課題を解決し、目的を達成するために、本発明は、ネットワークを介して接続される外部装置の状態を監視する通信装置であって、前記外部装置の状態を表す状態情報を記憶する記憶部と、正常に動作していることを確認する確認要求を前記外部装置から受信する要求受信部と、前記確認要求を受信後、次の前記確認要求を受信するまでの経過時間と時間閾値とを比較し、前記経過時間が前記時間閾値より大きい場合に、前記外部装置および前記通信装置のそれぞれに割り当てられた判定情報に基づいて、前記外部装置および前記通信装置のそれぞれが前記確認要求を送信する送信順位を決定する決定部と、S+W×n≧Tを満たす最小のn(ただし、Sは前記時間閾値、Wは予め定められた待機時間、nは0以上の整数、Tは前記経過時間を表す)を求め、n+3を順位閾値として決定し、前記通信装置の前記送信順位が前記順位閾値より小さい場合に、予め定められた期間ごとに前記確認要求を前記ネットワークに送信する通信部と、前記確認要求に対する応答を前記外部装置から受信する応答受信部と、前記応答を受信できない前記外部装置の前記状態情報を、異常が生じたことを表す状態情報に更新する更新部と、を備えることを特徴とする。
また、本発明は、上記装置で実行することができる方法およびプログラムである。
本発明によれば、他の装置を監視するためのメッセージを送信する装置に異常が発生した時に、当該メッセージの送信を代行する装置を適切に定めることにより、処理負荷の増大を回避することができるという効果を奏する。
第1の実施の形態にかかるビル監視制御システムの構成図である。 第1の実施の形態にかかる通信装置としてのデバイスのブロック図である。 従来手法にしたがって動作する各デバイスの動作を表す図である。 第1の実施の形態における起動開始処理の全体の流れを示すフローチャートである。 第1の実施の形態における監視処理の全体の流れを示すフローチャートである。 第1の実施の形態におけるデバイス群のアライブチェックの動作の具体例を示す図である。 第1の実施の形態で生じうる問題を説明するための図である。 第2の実施の形態にかかる通信装置としてのデバイスのブロック図である。 第2の実施の形態における監視処理の全体の流れを示すフローチャートである。 第2の実施の形態におけるデバイス群のアライブチェックの動作の具体例を示す図である。 第3の実施の形態にかかる通信装置としてのデバイスのブロック図である。 第3の実施の形態における停止判定処理の全体の流れを示すフローチャートである。 第1〜第3の実施の形態にかかる通信装置のハードウェア構成図である。
以下に添付図面を参照して、この発明にかかる装置、方法およびプログラムの最良な実施の形態を詳細に説明する。
(第1の実施の形態)
第1の実施の形態にかかる通信装置は、デバイス番号(またはデバイス番号とデバイス種別)からWho−Is送信順位を一意に決定し、決定したWho−Is送信順位からWho−Is送信を代替実行するかしないかを判断することにより、Who−IsとI−Amのブロードキャストの多発を回避する。なお、Who−Is送信順位とは、Who−Is送信を実行する優先順位を意味している。
図1は、第1の実施の形態にかかるビル監視制御システムの構成図である。図1に示すように、ビル監視制御システムは、他のデバイス(外部装置)を監視するデバイス(通信装置)として、監視サーバ1、監視サーバ2、LCS11、および、LCS12を備えている。各デバイスは、相互に他のデバイスの状態を監視することができる。
第1の実施の形態にかかるビル監視制御システムでは、通信プロトコルとしてBACnetを使用する。監視サーバ1、監視サーバ2、LCS11、およびLCS12は、BACnetプロトコルにより通信する。BACnetプロトコルにより通信するデバイスはそれぞれ固有のデバイス番号を持つ。本実施の形態では、監視サーバ1、監視サーバ2、LCS11、およびLCS12のデバイス番号を、それぞれ1、2、11、および12とする。ネットワークとしては、イーサネット(登録商標)などが使用される。なお、適用可能なシステムおよび通信プロトコルは、それぞれビル監視制御システムおよびBACnetプロトコルに限られるものではない。また、ネットワークをイーサネット(登録商標)以外により構成してもよい。
図2は、図1の監視サーバ1、監視サーバ2、LCS11、および、LCS12それぞれに相当するデバイス100の、アライブチェック機能にかかる機能構成を示すブロック図である。デバイス100は、通信部110と、I−Am監視部120と、Who−Is送信部130と、Who−Is監視部140と、アライブ情報記憶部150とを備える。
アライブ情報記憶部150は、デバイス100自身を含めたビル監視制御システムに参加している全デバイスのデバイス種別と、デバイス番号と、状態情報とを記憶する。デバイス種別とは、各デバイス(装置)の種別を表す情報(装置種別)であって、それぞれWho−Is送信の優先順位(デバイス種別の優先順位)が定められている。例えば、デバイス種別には、「監視サーバ」および「LCS」が含まれ、「監視サーバ」に対して「LCS」より大きい優先順位が定められる。デバイス種別や優先順位の決定方法はこれに限られるものではない。
デバイス番号とは、各デバイスを一意に識別する識別情報(識別番号)である。本実施の形態では、デバイス番号が小さいほどWho−Is送信順位(詳細は後述)が小さくなるように、各デバイスにデバイス番号を割り当てる。
状態情報とは、各デバイスの状態を表す情報である。例えば、デバイスが正常に動作しているか、デバイスに異常が生じているかを表す情報が、状態情報として記憶される。
なお、アライブ情報記憶部150は、HDD(Hard Disk Drive)、光ディスク、メモリカード、RAM(Random Access Memory)などの一般的に利用されているあらゆる記憶媒体により構成することができる。
通信部110は、他のデバイスとの間で各種情報を送受信する。通信部110は、要求受信部111と、応答受信部112と、を備えている。要求受信部111は、正常に動作していることを確認するための確認要求であるWho−Isを他のデバイスから受信する。応答受信部112は、Who−Isに対する応答であるI−Amを他のデバイスから受信する。
I−Am監視部120は、通信部110の応答受信部112が受信したI−Amを監視する。I−Am監視部120は、監視結果に応じてアライブ情報記憶部150を更新する更新部121を備えている。例えば、更新部121は、I−Amを受信したデバイスの状態情報を、正常に動作していることを表す状態情報に更新する。また、更新部121は、I−Amを受信しなかったデバイスの状態情報を、異常が生じたことを表す状態情報に更新する。
また、I−Am監視部120は、通信部110の要求受信部111がWho−Isを受信したときに、通信部110を介してI−Amをブロードキャストする。
Who−Is監視部140は、通信部110が受信したWho−Isを監視し、監視結果に応じてアライブ情報記憶部150を参照してWho−Is送信順位を計算する。Who−Is監視部140は、Who−Is送信順位を決定するための決定部141を備えている。具体的には、決定部141は、Who−Isの受信間隔(Who−Isを最後に受信してから次のWho−Isを受信するまでの経過時間)が、所定の閾値(時間閾値)より大きい場合に、各デバイスに割り当てられた判定情報からWho−Is送信順位を決定する。判定情報とは、Who−Is送信順位を決定するために用いられる情報であり、本実施の形態では、デバイス番号およびデバイス種別を判定情報として用いる。決定部141によるWho−Is送信順位の決定方法の詳細は後述する。
Who−Is送信部130は、Who−Is送信順位が、Who−Is送信を代替実行するか否かを決定するための閾値(順位閾値)より小さいか否かを判断し、小さい場合に、通信部110を介して、一定周期でWho−Isをブロードキャストする。
次に図3を用いて、従来手法の課題についてあらためて説明する。図3は、従来手法にしたがって動作する場合の監視サーバ1、監視サーバ2、LCS11、およびLCS12の各デバイスの動作を表す図である。同図の横軸は時間の経過を表している。また、監視サーバ1がWho−Is送信機能を実行しており、その他のデバイスはWho−Is監視機能を実行しているものとする。また、全デバイスがI−Am監視機能を実行しているものとする。
時刻0の時点で、監視サーバ1がWho−Isをブロードキャストし、それに対して他のデバイスがI−Amを返す。これにより、全デバイスは、他の全デバイスが正常であると判断し、アライブ情報記憶部150の状態情報を更新する。次に、監視サーバ1が異常終了したとする。この場合、時刻90の時点で、Who−Is監視機能を実行している監視サーバ2、LCS11、およびLCS12は、Who−Is送信が90秒途絶えたと判断し、Who−Isをそれぞれブロードキャストする。ブロードキャストされたWho−Isそれぞれに対して、全デバイスがI−Amをそれぞれ返信するため、デバイスの処理負荷の増加や、ネットワーク帯域の圧迫が発生する。
次に、このように構成された第1の実施の形態にかかるデバイス100による起動開始処理について図4を用いて説明する。起動開始処理とは、各デバイス100が起動したときの動作を表す処理である。図4は、第1の実施の形態における起動開始処理の全体の流れを示すフローチャートである。
ビル監視制御システムの全デバイス100は、起動するとI−Am監視機能を実行する(ステップS31)。これは、全てのデバイス100が、他の全てのデバイスの状態を把握することを意味する。
次に、デバイス100の決定部141が、自身のWho−Is送信順位を計算する(ステップS32)。決定部141は、アライブ情報記憶部150のデバイス種別とデバイス番号とからWho−Is送信順位を一意に決定する。本実施の形態では、デバイス種別が「監視サーバ」であるデバイスのほうが、「LCS」であるデバイスよりも上位とする。また、デバイス番号が小さいデバイスのほうが上位とする。
なお、デバイス番号のみで順位を決定してもよい。また、デバイス番号は、上記のように値が小さいほど優先順位が上位となるように割り当てる必要はない。例えば、一意に識別可能な任意のデバイス番号を割り当て、このデバイス番号と、Who−Is送信順位を決定するための優先順位(デバイス番号の優先順位)とを対応づけて管理するように構成してもよい。すなわち、決定部141が、このようにして割り当てられた優先順位等を判定情報としてWho−Is送信順位を決定するように構成してもよい。
他デバイスのデバイス種別やデバイス番号は、任意の方法で取得できる。例えば、設定ファイルとして各デバイスに他デバイスの情報を与えておく方法や、BACnetプロトコルに基づく通信を利用して他デバイスの情報を収集する方法などが適用可能である。
図1のデバイス群におけるWho−Is送信順位は、上位から順に監視サーバ1、監視サーバ2、LCS11、およびLCS12となる。したがって、図1のデバイス群が起動した場合、監視サーバ1がWho−Is送信を実行し、その他のデバイスはWho−Is監視を実行する。また、前述のとおり、全てのデバイスがI−Am監視を実行する。なお、Who−Is送信を実行するデバイスは、自身で発信したWho−Isに対してI−Amを送信する。
図4に戻り、決定部141は、決定した自身のWho−Is送信順位が1位であるか否かを判断し(ステップS32)、1位の場合(ステップS32:YES)、Who−Is送信機能の実行を開始する(ステップS33)。順位が1位でなければ(ステップS32:NO)、Who−Is監視を開始する(ステップS34)。
次に、このように構成された第1の実施の形態にかかるデバイス100による監視処理について図5を用いて説明する。監視処理とは、Who−Is監視デバイスとして機能するデバイス100がWho−Isを受信したときの動作を表す処理である。図5は、第1の実施の形態における監視処理の全体の流れを示すフローチャートである。
Who−Is監視デバイスの決定部141は、前回Who−Isを受信した時刻からの経過時間が時間閾値(例えば90秒)より大きいか否かを判断する(ステップS41)。すなわち、前回Who−Isを受信した時刻から90秒経過しているかどうかを判定する。90秒経過していなければ(ステップS41:NO)、所定の待機時間(例えば5秒)待機した後(ステップS42)、再び90秒経過しているかを判定する。
90秒経過していた場合(ステップS41:YES)、Who−Is送信部130は、自身のWho−Is送信順位が、アライブ情報記憶部150に正常に動作していることを表す状態情報が記憶されているデバイスの中で1位か2位であるか否かを判定する(ステップS43)。すなわち、Who−Is送信部130は、順位閾値を3(位)とし、自身のWho−Is送信順位が順位閾値(3位)より小さいか否かを判定する。
1位か2位であれば(ステップS43:YES)、Who−Is監視部140はWho−Is監視を停止し、Who−Is送信部130がWho−Is送信を開始する(ステップS44)。3位以下であれば(ステップS43:NO)、Who−Is監視部140はWho−Is監視を継続する(ステップS42)。
次に図6を用いて、第1の実施の形態におけるデバイス群のアライブチェックの動作の具体例を説明する。全てのデバイスが起動した場合、デバイス種別とデバイス番号とから、監視サーバ1がWho−Is送信を実行し、他デバイスはWho−Is監視を実行する。時刻0の時点でWho−IsとI−Amを送受信することで、全デバイスは、他の全デバイスが正常に動作していると判断する。
その後、監視サーバ1が異常終了したとすると、時刻90の時点で、他のデバイスはWho−Isが途絶えてから90秒が経過したと判断する。ここで、本実施の形態のデバイスは、自身のWho−Is送信順位を判断する。この時点では、全てのデバイスは監視サーバ1が正常に動作していると判断する。なぜなら、デバイスが異常であると判断するためには、I−Amが途絶えてから一定期間(非特許文献での推奨時間は150秒)経過する必要があるためである。
したがって、時刻90の時点では、自身のWho−Is送信順位を、正常であると判断しているデバイスの中で1位か2位であると判断するのは監視サーバ2のみである。このため、監視サーバ2は、Who−Is監視を停止し、Who−Is送信を開始する。LCS11とLCS12はWho−Is監視を継続する。
また、第1の実施の形態にかかるWho−Is送信デバイスは、自身よりもWho−Is送信順位が上位のデバイスからWho−Isを受信した場合、Who−Is送信を停止し、Who−Is監視を開始する。また、第1の実施の形態にかかるWho−Is監視デバイスは、自身よりも下位のデバイスからWho−Isを受信した場合、Who−Is監視を停止し、Who−Is送信を実行する。これにより、デバイスが異常終了と再起動を繰り返した場合でも、Who−Is送信順位が上位であるデバイスがWho−Is送信を実行することができる。
このように、第1の実施の形態にかかるデバイス(通信装置)によれば、デバイス種別とデバイス番号とから一意に定まるWho−Is送信順位に基づいて、Who−Is送信を代替実行するか否かを判断することで、Who−IsとI−Amのブロードキャストが多発することを避けることができる。なお、Who−Isが途絶えたと判断する時間である90秒は推奨値であり、必ずしも90秒である必要はない。待機時間(5秒)等についても同様である。
(第2の実施の形態)
第2の実施の形態は、第1の実施の形態で生じうる問題を解決可能にする。すなわち、第1の実施の形態では、Who−Isが送信されてから90秒以内に、Who−Is送信順位が1位と2位のデバイスが共に異常終了した場合に、第1の実施の形態の方法によるWho−Is送信の代替実行が行われず、ブロードキャストが多発するという問題が生じうる。
まず、図7を用いて、第1の実施の形態で生じうる問題の具体例について説明する。時刻0の時点でWho−IsとI−Amの送受信が行われ、全デバイスは、他の全デバイスが正常に動作していると判断する。その後、Who−Is送信順位の1位と2位である監視サーバ1と監視サーバ2とが共に異常終了したとする。この場合、時刻90の時点では、LCS11とLCS12とは、監視サーバ2がWho−Is送信を代替実行すると判断し、Who−Is監視を継続する。なぜなら、LCS11およびLCS12は、自身のWho−Is送信順位がそれぞれ3位および4位であると判断するからである。この結果、いずれのデバイスもWho−Isを送信せず、いずれのデバイスからもI−Amが送信されない状況になる。そして、時刻150の時点で、LCS11とLCS12は、他の全デバイスからI−Amが150秒送信されていないと判断し、自身以外の全デバイスを異常であると判断する。そして、Who−Is監視を停止し、Who−Is送信を実行する。この結果、ブロードキャストが多発し、処理負荷の増加や、ネットワーク帯域の圧迫が生じる。
第2の実施の形態にかかる通信装置(デバイス)は、Who−Isが途絶えてから90秒経過した後は、一定時間が経過するたびに、Who−Is送信を代替実行する権利を、Who−Is送信順位が下位のデバイスに段階的に与えていくことで、前述の第1の実施の形態で生じうる問題を解決する。
図8は、第2の実施の形態にかかる通信装置であるデバイス200の構成を示すブロック図である。図8に示すように、デバイス200は、通信部110と、I−Am監視部120と、Who−Is送信部230と、Who−Is監視部140と、アライブ情報記憶部150とを備える。
第2の実施の形態では、Who−Is送信部230の機能が第1の実施の形態と異なっている。その他の構成および機能は、第1の実施の形態にかかるデバイス100の構成を表すブロック図である図2と同様であるので、同一符号を付し、ここでの説明は省略する。
第1の実施の形態のWho−Is送信部130は、順位閾値を固定(3位)とし、自身のWho−Is送信順位が順位閾値より小さい1位か2位である場合に、Who−Is送信機能を開始していた。これに対し、第2の実施の形態のWho−Is送信部230は、時間閾値(例えば90秒)を超えてからの経過時間に応じて、順位閾値を段階的に変更する点が第1の実施の形態のWho−Is送信部130と異なっている。
次に、このように構成された第2の実施の形態にかかるデバイス200による監視処理について図9を用いて説明する。図9は、第2の実施の形態における監視処理の全体の流れを示すフローチャートである。
ステップS71からステップS72までは、第1の実施の形態にかかるデバイス100におけるステップS41からステップS42までと同様の処理なので、その説明を省略する。
Who−Is監視デバイスのWho−Is送信部230は、Who−Isが途絶えてから90秒以上経過した場合は(ステップS71:YES)、S+W×n≧Tを満たす最小のnを計算する(ステップS73)。ここで、Sは時間閾値(例えば90秒)、Wは予め定められた待機時間(例えば5秒)、nは0以上の整数、Tは、前回Who−Isを受信してから経過した時間(経過時間)を表す。時間閾値を90秒とし、待機時間を5秒とする場合は、同図に示すようにWho−Is送信部230は、90+5n≧Tを満たす最小のnを計算する。
そして、Who−Is送信部230は、自身のWho−Is送信順位が、正常に動作していると判断しているデバイスの中で(n+3)位よりも上位であるか否かを判定する(ステップS74)。すなわち、Who−Is送信部230は、順位閾値を(n+3)位とし、自身のWho−Is送信順位が順位閾値(n+3)位より小さいか否かを判定する。
(n+3)位よりも上位であれば(ステップS74:YES)、Who−Is監視部140はWho−Is監視を停止し、Who−Is送信部230がWho−Is送信を実行する(ステップS75)。(n+3)位よりも上位でなければ(ステップS74:NO)、Who−Is監視部140はWho−Is監視を継続し、5秒後に再び判定する(ステップS72)。
なお、例えば90秒以上経過した場合は、デバイス番号に等しい秒数だけ待機して、その間にWho−Isを受信しなければWho−Is送信を開始するということもできる。すなわち、例えば90秒に固定した時間閾値を用いる代わりに、固定の閾値(例えば90秒)を基準閾値とし、基準閾値にデバイス番号を加算した値を時間閾値として用いるように構成してもよい。
次に図10を用いて、第2の実施の形態におけるデバイス群のアライブチェックの動作の具体例を説明する。時刻0の時点でWho−IsとI−Amの送受信が行われ、全デバイスは、他の全デバイスが正常に動作していると判断する。その後、Who−Is送信順位の1位と2位である監視サーバ1と監視サーバ2とが共に異常終了したとする。時刻90の時点で、LCS11およびLCS12が、Who−Is代替実行の要否を判定する。この時点ではT=90であり、90+5n≧Tを満たす最小のnは0である。したがって、Who−Is送信順位が3位よりも上位であれば、Who−Is代替実行を実行する。LCS11は順位3位、LCS12は順位4位であるため、この時点では代替実行を実行しない。
5秒後、再びLCS11およびLCS12が、Who−Is代替実行の要否を判定する。この時点ではT=95であり、nは1となる。したがって、Who−Is送信順位が4位よりも上位であれば、Who−Is代替実行を実行する。LCS11は順位3位であるため、この時点でWho−Is監視を停止し、Who−Is送信の代替実行を開始する。仮にLCS11も異常終了していた場合は、時刻100の時点でLCS12がWho−Is送信を代替実行する。
なお、第1の実施の形態と同様に、第2の実施の形態にかかるWho−Is送信デバイスは、自身よりもWho−Is送信順位が上位のデバイスからWho−Isを受信した場合、Who−Is送信を停止し、Who−Is監視を開始する。また、第2の実施の形態にかかるWho−Is監視デバイスは、自身よりも下位のデバイスからWho−Isを受信した場合、Who−Is監視を停止し、Who−Is送信を実行する。これにより、デバイスが異常終了と再起動を繰り返した場合でも、Who−Is送信順位が上位であるデバイスがWho−Is送信を実行することができる。
このように、第2の実施の形態にかかるデバイス(通信装置)によれば、Who−Isが途絶えてから90秒経過した後は、一定時間が経過するたびに、Who−Is代替実行の権利を、Who−Is送信順位が下位のデバイスに段階的に与えていくことで、Who−IsとI−Amのブロードキャストが多発することを避けられる。なお、Who−Isが途絶えたと判断する時間である90秒や、Who−Is送信の代替実行を判定する周期である5秒は推奨値であり、必ずしもその値である必要はない。
(第3の実施の形態)
第1および第2の実施の形態のWho−Is送信デバイスは、自身よりもWho−Is送信順位が上位のデバイスからWho−Isを受信した場合、Who−Is送信を停止し、Who−Is監視を開始する。これにより、Who−Is送信順位が上位のデバイスのみがWho−Is送信を実行することができ、ブロードキャストの多発を抑えることができる。例えば、図1における監視サーバ2がWho−Is送信を実行している最中に、監視サーバ1からWho−Isを受信した場合、監視サーバ2はWho−Is送信を停止する。
監視サーバ2が、監視サーバ1からWho−Isを受信する状況は2通り考えられる。1つ目の状況(状況1)は、ネットワークの障害により監視サーバ1がネットワークから切断され、監視サーバ2がWho−Is送信を代替実行し、その後、監視サーバ1がネットワークに接続された場合である。この場合、監視サーバ1自体には障害が発生していないため、監視サーバ1はその後も60秒周期でWho−Isをブロードキャストする。
2つ目の状況(状況2)は、監視サーバ1に異常が発生し、監視サーバ2がWho−Is送信を代替実行し、その後、監視サーバ1が再起動した場合である。非特許文献1にて提案されているデバイスの起動時の動作によれば、デバイスは起動直後にBACnetのCOVNotificationメッセージ(以下、単にCOVNotificationという場合がある)をブロードキャストすることで、自身の状態を他デバイスに通知する。その後、デバイスはWho−Isをブロードキャストし、さらに監視制御に必要な情報を他デバイスから取得する初期化フェーズに移る。この場合、監視サーバ1はWho−Isを1回送信した後、初期化フェーズに入るため、初期化にかかる時間によっては、60秒後にWho−Isを送信できない可能性がある。
したがって、監視サーバ2は、状況1であれば、Who−Is送信を停止してよい。しかし、状況2であれば、監視サーバ1の初期化処理が60秒以上かかる(Who−Isが60秒後に送られてこない)可能性を考慮し、監視サーバ2はWho−Is送信を停止すべきではない。
第3の実施の形態にかかる通信装置は、このような状況を考慮し、上位のデバイスが初期化処理を実行しているか否かによってWho−Is送信の代替実行を停止するか否かを判断する。
図11は、第3の実施の形態にかかるデバイス300の構成を示すブロック図である。図11に示すように、デバイス300は、通信部310と、I−Am監視部120と、Who−Is送信部330と、Who−Is監視部140と、アライブ情報記憶部150とを備える。
第3の実施の形態では、通信部310に通知受信部313を追加したこと、および、Who−Is送信部330の機能が第1の実施の形態と異なっている。その他の構成および機能は、第1の実施の形態にかかるデバイス100の構成を表すブロック図である図2と同様であるので、同一符号を付し、ここでの説明は省略する。
通知受信部313は、起動した他のデバイスからCOVNotificationを受信する。
Who−Is送信部330は、Who−Is送信順位が上位である他のデバイスからWho−Isを受信した場合に、当該他のデバイスからCOVNotificationを受信しているか否かによって、Who−Is送信を継続するか停止するかを判定する機能が追加された点が、第1の実施の形態のWho−Is送信部130と異なっている。
次に、このように構成された第3の実施の形態にかかるデバイス300による停止判定処理について図12を用いて説明する。停止判定処理とは、Who−Is送信デバイスとして機能するデバイス300が、Who−Is送信順位が上位である他のデバイスからWho−Isを受信したときにWho−Is送信機能を停止するかを判定する処理である。図12は、第3の実施の形態における停止判定処理の全体の流れを示すフローチャートである。
以下では、Who−Is送信機能を代替実行しているデバイスである監視サーバ2が、Who−Is送信順位が上位である監視サーバ1からWho−Isを受信した場合を例に説明する。
すなわち、監視サーバ2がWho−Is送信を実行している最中に、監視サーバ1からWho−Isを受信したとする(ステップS91)。非特許文献1にて提案されているデバイスの起動時の動作によれば、起動デバイス(監視サーバ1)はWho−Is送信前に、COVNotificationメッセージをブロードキャストする。したがって、監視サーバ2のWho−Is送信部330は、監視サーバ1からWho−Isを受信する直前に、監視サーバ1からCOVNotificationを受信しているか否かを判定する(ステップS92)。
COVNotificationを受信していた場合(ステップS92:YES)、Who−Is送信部330は、Who−Is送信を停止せず、再度監視サーバ1からWho−Isを受信するまでWho−Is送信を継続する(ステップS93)。COVNotificationを受信していなければ(ステップS92:NO)、Who−Is送信部330はWho−Is送信を停止し、Who−Is監視部140がWho−Is監視を実行する(ステップS94)。
なお、上記説明では、上位のデバイスからWho−Isを2回受信した場合にWho−Is送信を停止していたが、Who−Isの受信回数は2回に限られるものではない。例えば、初期化に必要な時間に応じて定められたm回(mは2以上の整数)のWho−Isを受信した場合にWho−Is送信を停止するように構成してもよい。
このように、第3の実施の形態にかかるデバイス(通信装置)によれば、自身よりもWho−Is送信順位が上位のデバイスからWho−Isを受信した場合でも、上位デバイスが初期化処理に移る場合にはWho−Is送信を継続することができる。これにより、Who−Isの送信周期を一定に保つことができる。
次に、第1〜第3の実施の形態にかかる通信装置のハードウェア構成について図13を用いて説明する。図13は、第1〜第3の実施の形態にかかる通信装置のハードウェア構成図である。
第1〜第3の実施の形態にかかる通信装置は、CPU(Central Processing Unit)51などの制御装置と、ROM(Read Only Memory)52やRAM53などの記憶装置と、ネットワークに接続して通信を行う通信I/F54と、各部を接続するバス61を備えている。
第1〜第3の実施の形態にかかる通信装置で実行される通信プログラムは、ROM52等に予め組み込まれて提供される。
第1〜第3の実施の形態にかかる通信装置で実行される通信プログラムは、インストール可能な形式又は実行可能な形式のファイルでCD−ROM(Compact Disk Read Only Memory)、フレキシブルディスク(FD)、CD−R(Compact Disk Recordable)、DVD(Digital Versatile Disk)等のコンピュータで読み取り可能な記録媒体に記録して提供するように構成してもよい。
さらに、第1〜第3の実施の形態にかかる通信装置で実行される通信プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、第1〜第3の実施の形態にかかる通信装置で実行される通信プログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。
第1〜第3の実施の形態にかかる通信装置で実行される通信プログラムは、上述した各部(通信部、I−Am監視部、Who−Is送信部、Who−Is監視部)を含むモジュール構成となっており、実際のハードウェアとしてはCPU51が上記ROM52から通信プログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、各部が主記憶装置上に生成されるようになっている。
以上のように、本発明にかかる装置、方法およびプログラムは、ネットワークを介して接続された他のデバイスを監視する装置、方法およびプログラムに適している。
51 CPU
52 ROM
53 RAM
54 通信I/F
61 バス
1、2 監視サーバ
11、12 LCS
100、200、300 デバイス
110、310 通信部
111 要求受信部
112 応答受信部
120 I−Am監視部
121 更新部
130、230、330 Who−Is送信部
140 Who−Is監視部
141 決定部
150 アライブ情報記憶部
313 通知受信部

Claims (10)

  1. ネットワークを介して接続される外部装置の状態を監視する通信装置であって、
    前記外部装置の状態を表す状態情報を記憶する記憶部と、
    正常に動作していることを確認する確認要求を前記外部装置から受信する要求受信部と、
    前記確認要求を受信後、次の前記確認要求を受信するまでの経過時間と時間閾値とを比較し、前記経過時間が前記時間閾値より大きい場合に、前記外部装置および前記通信装置のそれぞれに割り当てられた判定情報に基づいて、前記外部装置および前記通信装置のそれぞれが前記確認要求を送信する送信順位を決定する決定部と、
    S+W×n≧Tを満たす最小のn(ただし、Sは前記時間閾値、Wは予め定められた待機時間、nは0以上の整数、Tは前記経過時間を表す)を求め、n+3を順位閾値として決定し、前記通信装置の前記送信順位が前記順位閾値より小さい場合に、予め定められた期間ごとに前記確認要求を前記ネットワークに送信する通信部と、
    前記確認要求に対する応答を前記外部装置から受信する応答受信部と、
    前記応答を受信できない前記外部装置の前記状態情報を、異常が生じたことを表す状態情報に更新する更新部と、
    を備えることを特徴とする通信装置。
  2. 前記判定情報は、前記外部装置および前記通信装置をそれぞれ識別する識別番号であり、
    前記決定部は、前記経過時間が前記時間閾値より大きい場合に、前記識別番号が小さいほど小さい前記送信順位を決定すること、
    を特徴とする請求項1に記載の通信装置。
  3. 前記判定情報は、前記外部装置および前記通信装置の種別を表す情報であって優先順位が定められた装置種別と、前記外部装置および前記通信装置をそれぞれ識別する識別番号と、であり、
    前記決定部は、前記経過時間が前記時間閾値より大きい場合に、前記装置種別の前記優先順位が小さく、かつ、前記識別番号が小さいほど小さい前記送信順位を決定すること、
    を特徴とする請求項1に記載の通信装置。
  4. 前記決定部は、前記経過時間と、予め定められた基準閾値に前記通信装置に割り当てられた識別番号を加算した値である前記時間閾値とを比較し、前記経過時間が前記時間閾値より大きい場合に、前記判定情報に基づいて前記送信順位を決定すること、
    を特徴とする請求項1に記載の通信装置。
  5. 前記通信部は、前記期間ごとに前記確認要求を前記ネットワークに送信する要求送信処理を開始した後、前記要求受信部によって、前記通信装置より前記送信順位が小さい前記外部装置から前記確認要求が受信された場合に、前記要求送信処理を停止すること、
    を特徴とする請求項1に記載の通信装置。
  6. 前記通信部は、さらに、前記要求受信部によって、前記通信装置より前記送信順位が大きい前記外部装置から前記確認要求が受信された場合に、前記期間ごとに前記確認要求を前記ネットワークに送信すること、
    を特徴とする請求項1に記載の通信装置。
  7. 前記要求受信部が前記確認要求を受信したときに、前記通信部は前記確認要求に対する応答を前記ネットワークに送信すること、
    を特徴とする請求項1に記載の通信装置。
  8. ネットワークを介して接続される外部装置の状態を監視する通信装置であって、
    前記外部装置の状態を表す状態情報を記憶する記憶部と、
    正常に動作していることを確認する確認要求を前記外部装置から受信する要求受信部と、
    前記確認要求を受信後、次の前記確認要求を受信するまでの経過時間と時間閾値とを比較し、前記経過時間が前記時間閾値より大きい場合に、前記外部装置および前記通信装置のそれぞれに割り当てられた判定情報に基づいて、前記外部装置および前記通信装置のそれぞれが前記確認要求を送信する送信順位を決定する決定部と、
    前記通信装置の前記送信順位と順位閾値とを比較し、前記通信装置の前記送信順位が前記順位閾値より小さい場合に、予め定められた期間ごとに前記確認要求を前記ネットワークに送信する通信部と、
    前記確認要求に対する応答を前記外部装置から受信する応答受信部と、
    前記応答を受信できない前記外部装置の前記状態情報を、異常が生じたことを表す状態情報に更新する更新部と、
    前記外部装置の起動を開始していることを表す起動通知を前記外部装置から受信する通知受信部と、を備え、
    前記通信部は、前記期間ごとに前記確認要求を前記ネットワークに送信する要求送信処理を開始した後、前記通知受信部によって前記起動通知が受信された場合は、前記要求受信部によって前記通信装置より前記送信順位が小さい前記外部装置からm回(mは2以上の整数)の前記確認要求が受信された場合に、前記要求送信処理を停止すること、
    を特徴とする通信装置。
  9. ネットワークを介して接続される外部装置の状態を監視する通信装置で実行される通信方法であって、
    前記通信装置は、前記外部装置の状態を表す状態情報を記憶する記憶部を備え、
    要求受信部が、正常に動作していることを確認する確認要求を前記外部装置から受信する要求受信ステップと、
    決定部が、前記確認要求を受信後、次の前記確認要求を受信するまでの経過時間と時間閾値とを比較し、前記経過時間が前記時間閾値より大きい場合に、前記外部装置および前記通信装置のそれぞれに割り当てられた判定情報に基づいて、前記外部装置および前記通信装置のそれぞれが前記確認要求を送信する送信順位を決定する決定ステップと、
    通信部が、S+W×n≧Tを満たす最小のn(ただし、Sは前記時間閾値、Wは予め定められた待機時間、nは0以上の整数、Tは前記経過時間を表す)を求め、n+3を順位閾値として決定し、前記通信装置の前記送信順位が前記順位閾値より小さい場合に、予め定められた期間ごとに前記確認要求を前記ネットワークに送信する送信ステップと、
    応答受信部が、前記確認要求に対する応答を前記外部装置から受信する応答受信ステップと、
    更新部が、前記応答を受信できない前記外部装置の前記状態情報を、異常が生じたことを表す状態情報に更新する更新ステップと、
    を備えることを特徴とする通信方法。
  10. 通信装置が備えるコンピュータを、
    ネットワークを介して接続される外部装置の状態を表す状態情報を記憶する記憶部と、
    正常に動作していることを確認する確認要求を前記外部装置から受信する要求受信部と、
    前記確認要求を受信後、次の前記確認要求を受信するまでの経過時間と時間閾値とを比較し、前記経過時間が前記時間閾値より大きい場合に、前記外部装置および前記通信装置のそれぞれに割り当てられた判定情報に基づいて、前記外部装置および前記通信装置のそれぞれが前記確認要求を送信する送信順位を決定する決定部と、
    S+W×n≧Tを満たす最小のn(ただし、Sは前記時間閾値、Wは予め定められた待機時間、nは0以上の整数、Tは前記経過時間を表す)を求め、n+3を順位閾値として決定し、前記通信装置の前記送信順位が前記順位閾値より小さい場合に、予め定められた期間ごとに前記確認要求を前記ネットワークに送信する通信部と、
    前記確認要求に対する応答を前記外部装置から受信する応答受信部と、
    前記応答を受信できない前記外部装置の前記状態情報を、異常が生じたことを表す状態情報に更新する更新部と、
    として機能させるための通信プログラム。
JP2009001120A 2009-01-06 2009-01-06 外部装置を監視する装置、方法およびプログラム Active JP5269619B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2009001120A JP5269619B2 (ja) 2009-01-06 2009-01-06 外部装置を監視する装置、方法およびプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2009001120A JP5269619B2 (ja) 2009-01-06 2009-01-06 外部装置を監視する装置、方法およびプログラム

Publications (2)

Publication Number Publication Date
JP2010161507A JP2010161507A (ja) 2010-07-22
JP5269619B2 true JP5269619B2 (ja) 2013-08-21

Family

ID=42578362

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009001120A Active JP5269619B2 (ja) 2009-01-06 2009-01-06 外部装置を監視する装置、方法およびプログラム

Country Status (1)

Country Link
JP (1) JP5269619B2 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6835526B2 (ja) * 2016-10-14 2021-02-24 アズビル株式会社 不正アクセス監視装置および方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006052928A (ja) * 2004-08-16 2006-02-23 Ipsquare Inc 空調管理システム
JP4626443B2 (ja) * 2005-08-19 2011-02-09 パナソニック電工株式会社 遠隔監視制御システム、ゲートウェイ装置、及びセンタサーバ

Also Published As

Publication number Publication date
JP2010161507A (ja) 2010-07-22

Similar Documents

Publication Publication Date Title
CA2733788C (en) Method and systems for redundant server automatic failover
KR20050098926A (ko) UPnP 장치의 변화에 반응하는 방법 및 시스템
JP2007133881A (ja) UPnPイベントに関する情報を効率的に送受信する方法及び装置
JP5269619B2 (ja) 外部装置を監視する装置、方法およびプログラム
JP2007233586A (ja) 二重化制御装置及び二重化制御方法
WO2010107117A1 (ja) 通信装置および通信方法
JP2007079726A (ja) 通信装置、通信状態検出方法及び通信状態検出プログラム
CN113467953A (zh) 服务状态的切换方法、装置、服务器及存储介质
CN113890986A (zh) 方法及监视摄像机
CN113965494A (zh) 用于冗余进程网络中的故障检测和角色选择的方法
US8335840B2 (en) Address distribution system and method and program for the same
JP5005425B2 (ja) 制御装置復帰システム
TW201408885A (zh) 風扇共用控制系統及方法
JP4863984B2 (ja) 監視処理プログラム、方法及び装置
JP5847064B2 (ja) 簡易型監視制御装置
JP4851994B2 (ja) 稼動監視装置、稼動監視方法および稼動監視プログラム
WO2005104435A1 (en) Methods, devices and computer program products using a node affiliation protocol for monitoring and/or controlling networkable devices
JP4327525B2 (ja) ケーブルモデムシステム
JP2024104182A (ja) 通信装置、通信方法およびプログラム
JP7600878B2 (ja) 情報処理装置及び復旧方法
JP7303083B2 (ja) 動作監視装置、動作監視方法、動作監視プログラム及び動作監視システム
JP7069883B2 (ja) 情報処理システム、情報処理装置、情報処理方法及びプログラム
WO2018146718A1 (ja) 空気調和装置
JP2022116401A (ja) 通信システム
CN119356697A (zh) 操作系统部署方法和装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20110324

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20121031

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20121120

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130104

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130205

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130312

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20130416

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130508

R151 Written notification of patent or utility model registration

Ref document number: 5269619

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151