JP2014146176A - デバイスの状態監視方法 - Google Patents

Abstract

【課題】 デバイスが抜去後すぐに再実装されたイベントを正確に検出する。
【解決手段】 状態監視要求メッセージの、メッセージフィールド３１には送信先アドレスが格納され、メッセージフィールド３２には送信元アドレスが格納され、メッセージフィールド３３にはメッセージ種別が格納され、メッセージフィールド３４にはデバイスの起動状態が格納され、メッセージフィールド３５にはシーケンス番号が格納され、メッセージフィールド３６にはメッセージチェックサムが格納されている。
【選択図】 図４

Description

本発明は、バスシステムにおけるデバイスの状態監視方法に関する。

各種の電子装置に組み込まれているバスシステムは制御部を持ち、バスにファン、温度センサなど様々なデバイスが接続され、各デバイスにより電子装置の冷却、温度や電圧の異常等を検知するために用いられる。

一般的にバスシステムでは、接続されている各デバイス自体の故障や未実装状態の検知のため、制御部は各デバイスに対して周期的にアクセスし、状態監視動作を行っている。

特許文献１にはこのような状態監視動作技術が開示されている。図１３はこの技術を示すブロック図である。マスタデバイス９０１がバスライン９１１に実装され、並列にスレーブデバイス９０２が実装されている。ここではスレーブデバイス９０２ａ、９０２ｂの２つが実装されている場合を例示する。

マスタデバイス９０１は障害検出のため、スレーブデバイス９０２ａに対し、定期的に動作確認信号９２１ａを送信する。スレーブデバイス９０２ａは動作確認信号９２１ａを受信すると、マスタデバイス９０１に対して動作応答信号９２２ａを送信する。マスタデバイス９０１は、動作応答信号９２２ａの受信タイミングを監視し、動作応答信号９２２ａを受信するとスレーブデバイス９０２ａが正常動作中と判断する。受信タイミングを超えた場合は再試行のために、動作確認信号９２１ａを再送信する。所定回数の再送信でも応答が得られなかった場合は、スレーブデバイス９０２に障害が発生したと判断する。スレーブデバイス９０２ｂに対しても同様に状態監視動作を行う。

以上説明した特許文献１の技術によれば、スレーブデバイスから障害発生通知が送信されなかったり、バスから抜去されたりした場合でも、当該スレーブの異常を短時間のうちに検出することができる。

特開昭６２−１７４８３８号公報

しかしながら、特許文献１の技術では、状態監視動作の再試行中、すなわち短時間のうちに、スレーブデバイスがバスから抜去、再実装されても、これを検出できない、という問題点があった。例えばスレーブデバイスが再試行中に交換された場合は、交換した事がログ（動作記録）に残らないため、保守管理に問題が発生する。

本発明は上記の問題に鑑みてなされたものであり、状態監視動作の再試行中にスレーブデバイスが抜去、再実装された場合にも、これを検出できる方法を提供する。

上記目的を達成するため本発明のデバイス状態監視方法では、バスに接続された制御部から、前記バスに接続されたデバイスに状体監視要求メッセージを送信する工程と、前記状体監視要求メッセージを前記デバイスが受信する工程と、前記デバイスが前記状体監視メッセージを起動後初めて受信したか既に受信した履歴があるかを示す起動情報を含む応答メッセージを前記制御部に送信する工程とを有する。

本発明の効果は、スレーブデバイスの実装状態を正確に検出できることである。特に抜去、再実装を検出できることである。

第１の実施の形態に用いるバスシステムを示すブロック図である。 状態監視要求メッセージのデータ構成を示す表である。 状態監視応答メッセージ（通常時）のデータ構成を示す表である。 状態監視応答メッセージ（起動時）のデータ構成を示す表である。 デバイス実装時のシーケンス図である。 デバイス抜去のイベントを含むシーケンス図である。 デバイス挿入のイベントを含むシーケンス図である。 デバイス抜去と再実装のイベントを含むシーケンス図である。 制御部の動作を示すフローチャートである。 デバイスの動作を示すフローチャートである。 第２の実施の形態を示すブロック図である。 第２の実施の形態で用いるデータフォーマットである。 特許文献１の技術を示すブロック図である。

次に、本発明の実施形態について図面を参照して説明する。

本実施の形態は、図１に示すような、バス１に接続された制御部２とデバイス３からなるシステムにおいて、制御部２から各デバイス３ａ、３ｂ、３ｃ、・・・に送信された状態監視要求メッセージに対し、デバイスが、自身の起動情報を含む状態監視応答メッセージを返信することを特徴とする。制御部２とデバイス３とはマスタとスレーブの関係にある。制御部２は変数として、メッセージシーケンス番号ＳＥＱＮｏおよび時間を計測するためのカウンタＣ１を保持する。デバイス３は変数としてメッセージシーケンス番号ＳＥＱＮｏおよび起動状態を示すＤｅｖＳｔａｔを保持する。ＤｅｖＳｔａｔは−１（値なし）、０(通常)、１（起動）の３値を取りうるものとする。Ｃ１は状態監視応答メッセージが返ってこない回数をカウントし、周期との対応を取ることで時間を計測する。

図２は、本実施の形態の状態監視要求メッセージ１０の例を示す表である。状態監視要求メッセージのメッセージフィールド１１には送信先アドレスが格納され、メッセージフィールド１２には送信元アドレスが格納され、メッセージフィールド１３には要求か応答かを示すメッセージ種別が格納され、メッセージフィールド１４にはシーケンス番号（ＳＥＱＮｏ）が格納され、メッセージフィールド１５にはメッセージチェックサムが格納されている。ここではデータとして、制御部２のアドレスを０、デバイスａ３ａのアドレスを１、メッセージ種別を要求の１としている。

図３は、通常時の状態監視応答メッセージ（通常時）２０の例を示す表である。通常時とは、バス１実装後既に動作確認が済んでいる状態、すなわち状態監視応答メッセージを送信した実績のある状態のことである。状態監視応答メッセージ２０のメッセージフィールド２１には送信先アドレスが格納され、メッセージフィールド２２には送信元アドレスが格納され、メッセージフィールド２３にはメッセージ種別が格納され、メッセージフィールド２４にはデバイスの起動状態（ＤｅｖＳｔａｔ）が格納され、メッセージフィールド２５にはシーケンス番号が格納され、メッセージフィールド２６にはメッセージチェックサムが格納されている。応答であるため、送信先アドレスは制御部１を示す０、送信元アドレスは１となっている。また、デバイスａ３ａが通常状態にあるため、デバイス起動状態は通常を示す０となっている。

図４は、起動時の状態監視応答メッセージ（起動時）３０の例を示す表である。起動時とは、バス１実装後、最初に状態監視要求メッセージを受信した状態のことである。状態監視応答メッセージの、メッセージフィールド３１には送信先アドレスが格納され、メッセージフィールド３２には送信元アドレスが格納され、メッセージフィールド３３にはメッセージ種別が格納され、メッセージフィールド３４にはデバイスの起動状態が格納され、メッセージフィールド３５にはシーケンス番号が格納され、メッセージフィールド３６にはメッセージチェックサムが格納されている。ここでは、デバイスａ３ａが起動状態にあるため、デバイス起動状態（ＤｅｖＳｔａｔ）は起動を示す１となっている。

以上のような、メッセージ形式とすることによって、制御部１はデバイス３が既に実装されていたもの（通常）か、新たに実装されたものかを識別することができる。

以上説明した状態監視動作について、図面を参照しながら説明する。以下、図に沿って順次動作を説明する。図中のＭｎ（ｎは自然数）はメッセージの通し番号である。
（通常状態）
まず、通常状態における動作について説明する。図５は通常時におけるメッセージのやり取りを示すシーケンス図である。

まず制御部から対象デバイスに対してＳＥＱＮｏ＝０を有する状態監視要求メッセージＭ１が送信される。

対象デバイスは、Ｍ１と同じシーケンス番号ＳＥＱＮｏ＝０および、通常の起動状態を表すＤｅｖＳｔａｔ＝０をデータとして有する状態監視応答メッセージＭ２を制御部に送信する。その後も周期的に同様のやり取りが行われる。

ここで何らかの理由により、図５Ｍ６のように応答メッセージが不達になる場合が考えられる。この場合、制御部は所定時間Ｔ１後に、同じシーケンス番号（ここではＳＥＱＮｏ＝２）を有する状態監視要求メッセージＭ７を送信する。

対象デバイスは前回と同じシーケンス番号の状態監視要求メッセージを受取ることで、前回送信した状態監視応答メッセージが不達になったことを認識できる。そこでＭ６と同じ内容の状態監視応答メッセージＭ８を再送信する。
（デバイス実装→デバイス抜去）
図６は実装されていたデバイスが状態監視動作中に抜去されるケースを含むシーケンス図である。

デバイスが実装されている状態では、通常時におけるメッセージのやり取りが行われている。

次いで、デバイスがＭ６の状態監視応答メッセージを送信した後、デバイスがバスから抜去されたとする。この時点では、実際の状態は「未実装」、制御部の判断結果は「実装」となっている。

次に制御部はデバイスに対し、状態監視要求メッセージＭ９を送信する。この時、デバイスが既に未実装になっているため状態監視応答メッセージが返ってこない。

応答がない場合、制御部は所定時間Ｔ１後に同じシーケンス番号（ＳＥＱＮｏ＝３）を持つ状態監視要求メッセージを再送信する。

以後、Ｔ１ごとに状態監視要求メッセージを再送信するが、デバイスがないため応答はない。

再送信を繰り返し、所定の時間Ｔ２が経過するとタイムアウトになり、制御部は対象デバイスが未実装であると判断する。
（デバイス未実装→実装）
図７はデバイスが未実装の状態から実装に変化したケースを含むシーケンス図である。

最初、制御部はＴ１ごとに状態監視要求メッセージを送信し、デバイスが未実装と判断している。

ここで図７のＭ２メッセージ送信後、デバイスが挿入、実装されたとする。デバイスは受信した状態監視要求メッセージと同じシーケンス番号ＳＥＱＮｏ＝０を有し、かつデバイスが起動状態にあることを示すＤｅｖＳｔａｔ＝１を有する状態監視応答メッセージＭ４を送信する。

次に制御部は状態監視要求メッセージＭ５を送信し、デバイスは状態監視応答メッセージＭ６を返信する。Ｍ６では、既に状態監視応答メッセージを一度返信しているため、デバイスの起動状態は通常時を表すＤｅｖＳｔａｔ＝０となっている。またシーケンス番号はメッセージのやり取りが成功したため１が加算されＳＥＱＮｏ＝１となる。以後、通常時の状態監視動作が継続される。
（デバイス実装→抜去→再実装）
図８はデバイスが実装された状態から、抜去され、タイムアウトする前に再実装されたケースを表すシーケンス図である。

メッセージＭ１からＭ６までは対象デバイスが実装されているため、通常時のやり取りが行われる。

次にデバイスが抜去される。デバイスが未実装となったため、制御部は時間Ｔ１ごとに状態監視要求メッセージを送信する。このとき返信がないため、シーケンス番号は変化しない。

次に、タイムアウトになる前に、デバイスが挿入、再実装される。この時点では、タイムアウトになっていないので、制御部はデバイスが実装中と判断している。

デバイスが再実装されると、デバイスは制御部から状態監視要求メッセージＭ１０を受信する。これに対し、デバイスは受信メッセージと同じシーケンス番号で、起動状態が起動時を示すＤｅｖＳｔａｔ＝１を格納した状態監視応答メッセージＭ１１を送信する。

次に仮にＭ１１が不達になったとする。すると制御部は前回Ｍ１０と同じシーケンス番号を有する状態監視要求メッセージを送信する。デバイスはシーケンス番号が前回と同じであるため、応答メッセージが不達になったことを識別する。そして、同じシーケンス番号、同じ起動状態（ＤｅｖＳｔａｔ＝１）の状態監視応答メッセージＭ１３を再送信する。

次に、制御部が状態監視応答メッセージの受信に成功する。制御部は起動状態が起動（ＤｅｖＳｔａｔ＝１）となっていることにより、デバイスが実装状態から、抜去後再実装に変化したと判断する。

次いで、制御部はシーケンス番号を一つ加算した状態監視要求メッセージを送信する。デバイスはシーケンス番号が変化しているため制御部が状態監視応答メッセージの受信に成功したことを識別する。このため起動状態が通常であるＤｅｖＳｔａｔ＝０とした状態監視応答メッセージＭ１５を送信する。以降は通常時のメッセージのやり取りが行われる。

以上の動作とすることにより、デバイス抜去後、タイムアウト前に再実装された場合でも、実装と再実装を識別することができる。

次に、前述の動作の実現手段について図面を参照しながら説明する。図９は制御部の動作を示すフローチャートである。

まず制御部はシーケンス番号としてＳＥＱＮｏ＝０、状態監視応答メッセージが返ってこない時間を計測するためのカウンタにＣ１＝０を代入する（ｓｔｅｐ１）。前述したようにＣ１はデバイス未実装時の状態監視応答メッセージ送信回数をカウントする手段である。

次に制御部は対象デバイスに対して状態監視要求メッセージを送信する（ｓｔｅｐ２）。

所定時間Ｔ１以内に状態監視応答メッセージを受信した場合（ｓｔｅｐ３、ＹＥＳ）は、状態監視応答メッセージ中の起動状態が起動であるか通常であるか識別する。起動状態でなかった場合（ｓｔｅｐ５、ＮＯ）は、制御部は対象デバイスが実装されていると判断する（ｓｔｅｐ６）。次にシーケンス番号ＳＥＱＮｏに１を加算し（ｓｔｅｐ８）、カウンタＣ１に０を代入し（ｓｔｅｐ９）、状態監視要求メッセージ送信前のＡに戻る。起動状態が起動であった場合（ｓｔｅｐ５、ＹＥＳ）は、対象デバイスが新規に実装されたと判断する（ｓｔｅｐ７）。次いで、次にシーケンス番号ＳＥＱＮｏに１を加算し（ｓｔｅｐ８）、カウンタＣ１に０を代入し（ｓｔｅｐ９）、状態監視要求メッセージ送信前のＡに戻る。

ｓｔｅｐ３において制御部が時間Ｔ１以内に状態監視応答メッセージを受信できなかった場合（ｓｔｅｐ３、ＮＯ）は、制御部はカウンタＣ１に１を加算する（ｓｔｅｐ４）。次にＣ１がタイムアウトを示す既定値に達したか否かを判別する（ｓｔｅｐ１０）。Ｃ１が既定値に達していた場合（ｓｔｅｐ１０、ＹＥＳ）は、対象デバイスが未実装であると判断する（ｓｔｅｐ１１）。次いで、カウンタに０を代入して時間をリセットし（ｓｔｅｐ１２）、Ａに戻る。Ｃ１が既定値に達していなかった場合は、デバイスが実装されているか否かの判断を保留し、前回の判断結果を保持する（ｓｔｅｐ１３）。次にカウンタの値を保持したままＡに戻る。すなわち周期Ｔ１での状態監視要求メッセージ送信を継続する。

次に、デバイス側の動作について説明する。図１０はデバイスの動作を示すフローチャートである。

初期状態として、デバイスはシーケンス番号および、デバイスの起動状態のデータを持たない。すなわちＳＥＱＮｏ＝−１（値なし）およびＤｅｖＳｔａｔ＝−１（値なし）が代入される（ｓｔｅｐ１）。

次にデバイスは状態監視要求メッセージを受信する（ｓｔｅｐ２）。これに対し、受信した状態監視要求メッセージと同じＳＥＱＮｏと起動状態が起動であることを示すＤｅｖＳｔａｔ＝１を代入した状態監視応答メッセージを返信する（ｓｔｅｐ３）。次にデバイスは、送信したＳＥＱＮｏを自身の記憶部に保存する（ｓｔｅｐ４）。また送信したＤｅｖＳｔａｔ＝１を保存する（ｓｔｅｐ５）。

次にデバイスは次の状態監視要求メッセージを受信する（ｓｔｅｐ６）。次に受信したメッセージのＳＥＱＮｏと自身が保存しているＳＥＱＮｏを比較する（ｓｔｅｐ７）。ＳＥＱＮｏが同じであった場合（ｓｔｅｐ７、ＹＥＳ）は、前回送信した状態監視応答メッセージが不達であったと判断する。そして受信したＳＥＱＮｏ＝保存しているＳＥＱＮｏと保存しているＤｅｖＳｔａｔの値を代入した前回と同じ内容の状態監視応答メッセージを再送信する（ｓｔｅｐ８）。

ｓｔｅｐ７においてＳＥＱＮｏが保存しているＳＥＱＮｏと異なっていた場合（ｓｔｅｐ７、ＮＯ）は前回送信した状態監視応答メッセージが正しく受信されたと判断し、状態監視応答メッセージに今回受信したＳＥＱＮｏを代入し、通常状態を表すＤｅｖＳｔａｔ＝０を代入した状態監視応答メッセージを送信する（ｓｔｅｐ９）。次に送信したＳＥＱＮｏを保存する（ｓｔｅｐ１０）。次に送信したＤｅｖＳｔａｔ（この場合は０）を保存して（ｓｔｅｐ１１）ｓｔｅｐ６の前であるＢに戻る。

以上説明した構成、動作により、本実施の形態を用いれば、バスにデバイスが実装された状態、実装されていない状態、抜去された状態、再実装（交換）された状態などを正しく判断できる。このため、正しいイベントログが記録される。
（第２の実施の形態）
本実施の形態ではバスシステムとしてＩ２Ｃバスを採用している。Ｉ２Ｃバスは、フィリップス社が提唱しているシリアル通信規格であり、２本の信号線に対し、マスタ、スレーブを並列に接続する。Ｉ２Ｃバスを用いると、比較的簡単な構成で多様なアプリケーションを実現できる。

図１１は本発明第２の実施の形態を示すブロック図である。Ｉ２Ｃバスシステム１００はクロック信号線ＳＣＬ１１１とデータ信号線ＳＤＡ１１２の２本の信号線からなるＩ２Ｃバス１１０と、これに実装された制御部１０１（マスタ）とスレーブデバイス１０５を有する。ここではスレーブデバイス１０５が複数あり、それぞれ１０５ａ、１０５ｂ、１０５ｃ、・・・と記載している。スレーブデバイス１０５の具体例としては、ファン、温度センサ、ＥＥＰＲＯＭ、回線カードなど様々ものを用いることが出来る。

制御部１０１はＣＰＵ１０２とメモリ１０３とバスを制御するＩ２Ｃバスマスタ１０４を有している。

ＳＣＬ１１１、ＳＤＡ１１２はそれぞれプルアップ抵抗１１３を介して、電源ラインＶｄｄ１１４に接続されている。

制御部１０１からは状態監視要求メッセージが各スレーブデバイス１０５に送信され、各スレーブデバイス１０５は状態監視応答メッセージを送信する。動作は第１の実施の形態に記載した通りである。

Ｉ２Ｃバスシステムではデータフォーマットが規定されている。図１２に、このＩ２Ｃデータフォーマット２００を示す。Ｓ２０１はスタート条件であり、通信の開始に当たる。次に７ビットのＳｌａｖｅＡｄｄｒｅｓｓ２０２が続く。Ｒ／Ｗ２０３はデータ転送がマスタからの書き込みか、読み出しかのメッセージ種別を定義する。ＡＣＫ２０４はスレーブがデータを受信したことをマスタに伝達する肯定応答である。ＤＡＴＡ２０５はデータが入る領域である。Ｐ２０６はストップ条件で、通信の終了を定義する。

本実施の形態では上述のデータフォーマットに従い、ＤＡＴＡ２０５の領域にＳＥＱＮｏ、ＤｅｖＳｔａｔなどを記述して、状態監視動作を行う。

なお第１の実施の形態における説明から明らかなように、本発明はＩ２Ｃ以外のバスシステムに対しても同様に適用可能である。

以上、説明したように本発明によれば、バスへのデバイスの実装状態を正しく判断できる。

１ バス
２ 制御部
３ デバイス
１０ 状態監視要求メッセージ
２０ 状態監視応答メッセージ（通常時）
３０ 状態監視応答メッセージ（起動時）
１００ Ｉ２Ｃバスシステム
１０１ 制御部
１０２ ＣＰＵ
１０３ メモリ
１０４ Ｉ２Ｃバスマスタ
１０５ スレーブデバイス
１１０ Ｉ２Ｃバス
１１１ ＳＣＬ
１１２ ＳＤＡ
１１３ プルアップ抵抗
１１４ Ｖｄｄ
２００ Ｉ２Ｃデータフォーマット
９０１ マスタデバイス
９０２ スレーブデバイス
９１１ バスライン
９２１ 動作確認信号
９２２ 動作応答信号

Claims (8)

1. バスに接続された制御部から、前記バスに接続されたデバイスに状体監視要求メッセージを送信する工程と、前記状体監視要求メッセージを前記デバイスが受信する工程と、前記デバイスが前記状体監視メッセージを起動後初めて受信したか既に受信した履歴があるかを示す起動情報を含む応答メッセージを前記制御部に送信する工程とを有することを特徴とするデバイスの状態監視方法。
2. 前記制御部が前記状態監視要求メッセージにシーケンス番号を付与する工程と、前記デバイスが受信した前記状態監視要求メッセージと同じシーケンス番号を前記状態監視応答メッセージに付与する工程を有することを特徴とするデバイスの状態監視方法。
3. 前記デバイスが受信した前記状態監視要求メッセージの前記シーケンス番号が同じだった場合には、前回送信した前記状態監視要求メッセージと同じ前記起動情報を前記状態監視応答メッセージに代入する工程を有することを特徴とする請求項２に記載のデバイスの状態監視方法。
4. 前記制御部が前記状体監視要求メッセージを定期的に送信する工程を有することを特徴とする請求項１乃至請求項３いずれか一項に記載のデバイスの状態監視方法。
5. 前記制御部が前記状態監視要求メッセージに対する前記状態監視応答メッセージを受信できなかった場合に、所定回数リトライする工程を有することを特徴とする請求項１乃至請求項４いずれか一項に記載のデバイスの状態監視方法。
6. 前記制御部が前記リトライを所定回数行っても前記状態監視応答メッセージを受信できなかった場合に、前記デバイスが未実装であると判断する工程を有することを特徴とする請求項５に記載のデバイスの状態監視方法。
7. 前記制御部が前記リトライ中に前記状態監視応答メッセージを受信した場合に、前記制御部が前記起動情報を参照し前記デバイスが新規に実装されたものであるか否かを判別する工程を有することを特徴とする請求項５または請求項６に記載のデバイスの状態監視方法。
8. 前記バスがＩ２Ｃバス（Ｉｎｔｅｒ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｂｕｓ）であることを特徴とする請求項１乃至請求項８いずれか一項に記載のデバイスの状態監視方法。

Images