JP3942216B2 - 二重化された監視／制御プロセッサによるシステム監視・制御方法およびシステム監視・制御装置 - Google Patents
二重化された監視／制御プロセッサによるシステム監視・制御方法およびシステム監視・制御装置 Download PDFInfo
- Publication number
- JP3942216B2 JP3942216B2 JP31079596A JP31079596A JP3942216B2 JP 3942216 B2 JP3942216 B2 JP 3942216B2 JP 31079596 A JP31079596 A JP 31079596A JP 31079596 A JP31079596 A JP 31079596A JP 3942216 B2 JP3942216 B2 JP 3942216B2
- Authority
- JP
- Japan
- Prior art keywords
- monitoring
- scf
- processor
- notification event
- controlling
- 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.)
- Expired - Lifetime
Links
Images
Landscapes
- Debugging And Monitoring (AREA)
- Stored Programmes (AREA)
- Hardware Redundancy (AREA)
Description
【０００１】
【発明の属する技術分野】
中規模以上の計算機システムにおいては、通常、メインプロセッサとは独立して、環境、装置、電源といったシステムの監視、制御、保守の機能を担当する監視／制御プロセッサが設けられる（以下、これを必要に応じてＳＣＦ：ＳｙｓｔｅｍＣｏｎｔｒｏｌＦａｃｉｌｉｔｙと呼ぶ）。
本発明は、同一システム内に二重化された監視／制御プロセッサを持つ計算機システムに関し、特に、本発明は二重化された監視／制御プロセッサによるシステムの監視・制御方法およびシステム監視・制御装置に関するものである（以下、上記二重化監視／制御プロセッサ間の通信を必要に応じてＳＣＦ間通信またはＳＣＦＬｉｎｋと呼ぶ）。
【０００２】
【従来の技術】
従来から、資源を二重化した計算機システムが知られているが、これらのシステムにおいては、ＳＣＦ自体は一つであったため、ＳＣＦ自体が故障した場合は、システムとして動作不能（システムダウン）となった。
また、ＳＣＦ自体を二重化する試みもなされているが、ＳＣＦを二重化した場合でも、従来においては両ＳＣＦ間通信が行えなかったため、共通資源の排他制御や片系資源の故障時の動作保証が困難であった。
【０００３】
【発明が解決しようとする課題】
同一システム内で各種資源を二重化することにより、システムとしてノーダウン、ノーストップを可能とする高信頼性システムを実現することができる。
しかしながら、資源を二重化した場合、それぞれの資源をＳＣＦが監視／制御して一つのシステムの動作を実現しなければならず、また、共通資源については、各ＳＣＦ間での制御が競合しないように排他制御を行う必要があり、常に他系の状態を監視し、把握しておく必要がある。
【０００４】
本発明は上記した事情に鑑みなされたものであって、本発明の第１の目的は、二重化したＳＣＦ間での通信処理を実現可能とすることにより、両ＳＣＦ間の処理に一貫性を持たせるとともに、片系異常時でも適切な処理を迅速に行うことを可能とし、ノーストップ・システムを実現することである。
本発明の第２の目的は、共通資源の排他制御や、片系故障時の切り離し処理および他系資源の監視引き継ぎを容易にすることである。
本発明の第３の目的は、二重化した両ＳＣＦ間の通信異常を迅速に検出し、ハード異常なのか他系未実装による通信異常なのかを認識できるようにするとともに、受信エラーの検出や受信エラー発生時の他系への通知処理および再送事象の検索処理を容易にすることである。
【０００５】
本発明の第４の目的は、システム動作中のまま、片系のＳＣＦを交換することを可能とするとともに、活性挿入されたＳＣＦに対して、動作中のＳＣＦの内部情報を引き継ぐことができるようにし、あたかもずっと二重化状態で動いていたように動作をさせることである。
本発明の第５の目的は、二重化した両ＳＣＦ間でお互いの機能レベルの自動認識を可能とすることにより、機能版数が異なった状態で動作することをなくし、二重化システムの動作を常に保証することである。
本発明の第６の目的は、他系の自己診断時の異常を迅速に検出できるようにし、自己診断異常時に適切な処理を行えるようにすることである。
【０００６】
【課題を解決するための手段】
図１は本発明の原理図である。同図において、１はメインプロセッサ、２はメインプロセッサと監視／制御プロセッサ間を接続するバス、３ａ，３ｂは、監視、制御、保守等を行う監視／制御プロセッサであり、監視／制御プロセッサ３ａ，３ｂは同一の構成を有し、両系の間に通信手段４が設けられている。
５は監視／制御プロセッサ３ａ，３ｂがそれぞれ監視・制御する固有資源、６は監視／制御プロセッサ３ａ，３ｂの両方が監視・制御する共有資源である。
【０００７】
図１に示すように、本発明においては次のようにして前記課題を解決する。
（１）メインプロセッサ１とは独立して設けられたシステムの監視、制御、保守を行うための監視／制御プロセッサを二重化し、二重化された監視／制御プロセッサ３ａ，３ｂによりシステムの監視・制御を行う前記二重化された監視／制御プロセッサにより、情報処理システムの監視・制御を行う情報処理装置のシステム監視・制御方法において、監視／制御プロセッサ３ａ，３ｂ間相互で通信を行うための通信手段４を設け、前記二重化された監視／制御プロセッサのうち、送信権を有する他の監視／制御プロセッサから通知事象を受信したとき、一の監視／制御プロセッサが通知事象の送信権を獲得するステップと、前記一の監視／制御プロセッサが、他の監視／制御プロセッサへの通知事象に、シーケンス番号を付与するステップと、前記一の監視／制御プロセッサが、シーケンス番号が付与された通知事象を前記他の監視／制御プロセッサに送信するステップと、前記他の監視／制御プロセッサから受信エラーの発生を原因とする再送依頼が前記シーケンス番号を用いてなされたときに、前記他の監視／制御プロセッサからの受信したシーケンス番号が付与されている通知事象を前記他の監視／制御プロセッサに再送するステップを設ける。
【０００８】
（２）上記（１）において、通知事象の送信権の放棄を行うステップをさらに有し、前記ステップは、通知事象の送信権を獲得した一の監視／制御プロセッサが、送信権の獲得から一定時間が経過することにより保持時間タイムアウトが発生した場合に、他の監視／制御プロセッサに対して通知事象を送信することにより、前記通知事象の送信権の放棄を行う。
（３）上記（２）において、前記一の監視／制御プロセッサが、送信権を有する他の監視／制御プロセッサから通知事象の送信権を獲得するステップは、送信権を有さない一の監視／制御プロセッサにおいて、前記送信権放棄から一定時間の経過により獲得時間のタイムアウトが発生した場合に、前記一の監視／制御プロセッサが通知事象の送信権を獲得する。
【０００９】
（４）上記（３）において、エラー判定を行うステップをさらに有し、前記ステップは、前記獲得時間のタイムアウトが発生した場合に、他の監視／制御プロセッサで前記送信権を獲得した一の監視／制御プロセッサにおいてエラーが発生したものと判断するステップである。
（５）情報処理装置のシステム監視・制御装置において、メインプロセッサとは独立して設けられ、情報処理システムの監視、制御又は保守を行うための二重化された監視／制御プロセッサと、前記二重化された監視／制御プロセッサ間で、通知事象の通信を行なうための通信手段とを有し、前記二重化された監視／制御プロセッサのうち一の監視／制御プロセッサは、送信権を有する他の監視／制御プロセッサから通知事象を受信したとき通知事象の送信権を獲得し、他の監視／制御プロセッサへの通知事象にシーケンス番号を付与し、前記シーケンス番号を付与された通知事象を、他の監視／制御プロセッサに送信するとともに、前記他の監視／制御プロセッサから受信エラーの発生を原因とする再送依頼が前記シーケンス番号を用いてなされたときに、前記他の監視／制御プロセッサからの受信したシーケンス番号が付与されている通知事象を前記他の監視／制御プロセッサに再送する。
【００１０】
（６）上記（５）において、二重化された監視／制御プロセッサはそれぞれ送信権保持タイマを有し、通知事象の送信権を獲得した一の監視／制御プロセッサにおいて、前記送信権保持タイマが、送信権の獲得から一定時間の経過によりタイムアウトが発生した場合に、他の監視／制御プロセッサに対して通知事象を送信することにより、前記通知事象の送信権の放棄を行う。
【００１１】
（７）上記（６）において、二重化された監視／制御プロセッサはそれぞれ送信権獲得タイマを有し、送信権を有さない一の監視／制御プロセッサにおいて、前記送信権の放棄から一定時間の経過により、前記送信権獲得タイマにタイムアウトが発生した場合に、前記一の監視／制御プロセッサに通知事象の送信権を付与する。
【００１２】
（８）上記（７）おいて、二重化された監視／制御プロセッサはそれぞれ、前記送信権獲得タイマにおいてタイムアウトが発生した場合に、他の監視／制御プロセッサでエラーが発生したものと判断する。
【００１３】
以上のように、本発明においては、お互いの状態を把握しながらメインプロセッサに対して同じ動作を行うことができ、二重化された監視／制御プロセッサに全体として一つの動作を行わせることができる。
また、片系異常時、これを迅速に検出し、適切な処理（システムダウンしないように、正常な系で制御）を継続することが可能となる。
また、送受信した全ての事象をシーケンス番号により管理することができ、送信側では、送信した事象の記憶と、再送依頼時の再送事象の取り出しが容易となる。
さらに、受信側では、事象単位のシーケンスチェックによって、未受信事象の検出が可能となり、送信側への再送依頼もエラーとなったシーケンス番号を通知するだけでよく、処理が簡略化される。
【００１４】
さらに、一定時間、事象（ alive message) が通知されなかったことをタイマのタイムアウトにより知ることができ、タイムアウトにより他系に何らかの異常が発生したことを知ることが可能となる。
また、上記事象（ alive message) の送信権をいずれか一方の系が持つという機能を利用することにより、共通資源のアクセス権等の排他制御を行うことが可能となる。
また、通信異常を全て受信側で検出することができ、また、検出機構によって通信異常の原因の予測が可能となり、通信異常に対して適切な処理を行うことが可能となる。
また、通信異常が発生した場合、これをいち早く検出し、適切な処理を行うことによって、通信異常が発生した場合であってもシステムの動作を保証することができる。
【００１８】
【発明の実施の形態】
図２は、本発明の実施例のシステムの構成と監視資源を示す図である。同図において、１０はメインプロセッサ、１２，１３は二重化されたＳＣＦであり（ＳＣＦ１２，１３を、それぞれ＃Ａ系ＳＣＦ１２、＃Ｂ系ＳＣＦ１３という）、＃Ａ系、＃Ｂ系のＳＣＦ１２，１３は同一の構成を備えている。
上記メインプロセッサ１０と各ＳＣＦ１２，１３はＳＣバス（ＳＣＦとメインプロセッサ間通信線）１１で接続されている。
１４はＳＣＦ１２，１３をハード的に接続する信号線（ＳＣＦＬｉｎｋ）であり、後述するようにＳＣＦ間通信レジスタに接続されている。
１５はＲＳ２３２Ｃインタフェース、１６は外部無停電電源装置（外部ＵＰＳ）、１７は外部設備、ＥＰＣは外部電源制御インタフェース、１８は拡張装置、ＲＣＩは拡張装置制御インタフェース、１９は拡張装置電源、ＥＤＰＣＩは拡張装置電源制御インタフェース、２０は温度センサ、２１はファンである。
また、２２はオペレータ操作パネル、２３はサブ電源装置（ＰＳＵ）、２４は内蔵無停電電源装置（ＵＰＳ）、２５はメイン電源装置（ＰＤＵ）である。
【００１９】
図２に示すように、各ＳＣＦ１２，１３には二重化された監視資源が接続されているが、外部無停電電源装置（外部ＵＰＳ）１６、拡張筐体制御インタフェースＲＣＩ、温度センサ２０等は固有資源である。
また、メイン電源（ＰＤＵ）２５、内蔵無停電電源装置（ＵＰＳ）２４、ファン２１、オペレータ操作パネル２２等は共用資源であり、両系から監視可能であ。
それぞれのＳＣＦ１２，１３は、上記したようにＳＣバス１１によってメインプロセッサと接続されているが、両系で監視している資源の事象は、いずれかの系から一回だけ通知する必要があり、また、他系の通知担当資源の事象でも、例えば、いずれかのＳＣバスが断線した場合等には、正常な系から代替通知が行えるように構成されている。
【００２０】
次に本発明の実施例の各部の構成および動作について説明する。
（１）ＳＣＦ間通信
図３は本発明の実施例のＳＣＦ間通信の概略構成を示す図である。同図において、１０はメインプロセッサ、１１はＳＣバス、１２，１３は二重化されたＳＣＦボードである。
＃Ａ系ＳＣＦボート１２、＃Ｂ系ＳＣＦボード１３は、ＳＣＦ間通信を行うため、それぞれＳＣＦ間通信用レジスタ１２ａ，１３ａを備えており、ＳＣＦ間通信用レジスタ１２ａ，１３ａは受信用レジスタＥＣＯＭＲ１と送信用レジスタＥＣＯＭＲ２から構成されている。
＃Ａ系ＳＣＦボード１２の受信用レジスタＥＣＯＭＲ１と＃Ｂ系ＳＣＦボード１３の送信用レジスタＥＣＯＭＲ２はハード的にシリアル転送を行う信号線１４により接続されており、また、＃Ｂ系ＳＣＦボード１２の受信用レジスタＥＣＯＭＲ１と＃Ａ系ＳＣＦボード１２の送信用レジスタＥＣＯＭＲ２は、同様な信号線１４により接続されており、送信用レジスタＥＣＯＭＲ２にデータを書き込むと、他系のＳＣＦに送信され、受信用レジスタＥＣＯＭＲ１に上記データが書き込まれる。
１２ｂ，１３ｂは送受信処理を行うＳＣＦファームウエア、１２ｃ，１３ｃはＳＣＦ制御用ＣＰＵである。
【００２１】
図４は、ＳＣＦ間通信用レジスタ１２ａ，１３ａにおける受信用および送信用レジスタＥＣＯＭＲ１，ＥＣＯＭＲ２の構成を示す図である。
受信用および送信レジスタＥＣＯＭＲ１，ＥＣＯＭＲ２は同図に示すように、１６ビット構成であり、下位９ビット（ＦＣＲ，ＥＣＯＮＤ）は共通のデータ領域、ビット１５（ＩＮＴ）は割り込みに使用される。
送信用レジスタＥＣＯＭＲ２のＩＮＴビットに１を設定すると他系の受信用レジスタＥＣＯＭＲ１のＩＮＴビットに１がセットされ、その系のＳＣＦ制御用ＣＰＵに割り込みが通知される。
また、ビット１４（ＰＥＲＲ）にはパリティ異常時に１がセットされる。
すなわち、１６ビットのレジスタに１ビットのパリティがハードウェアで付加され、受信時にハードウェアでパリティチェックを行い、パリティ異常時にビット１４（ＰＥＲＲ）に１がセットされる。
【００２２】
図３、図４において、送信側のＳＣＦファームウェア１２ｂまたは１３ｂは他系への通知事象が発生すると、通知データを送信用レジスタＥＣＯＭＲ２に書き込み、ＩＮＴビットに１をセットする。
このデータは信号線１４を介して受信側のＳＣＦに送信され、受信用レジスタＥＣＯＭＲ１に書き込まれる。
受信用レジスタＥＣＯＭＲ１のＩＮＴビットに１が書き込まれると、ＳＣＦ制御用ＣＰＵに割り込みが上がり、ＣＰＵから起動されたＳＣＦファームウェア１２ｂまたは１３ｂの割り込みハンドラは受信用レジスタＥＣＯＭＲ１を読み取り、ＳＣＦ間通信が実現される。
【００２３】
図５はＳＣＦ間通信レジスタのアクセス方法を示す図である。
本実施例のＳＣＦ間通信レジスタ１２ａ，１３ａは、同図に示すように、１バイトずつのＲＥＡＤ／ＷＲＩＴＥしか行うことができない。
従って、複数バイトを送受信できるようにするため、コマンド方式によりデータ送信を行い、送信するデータ長をコマンド毎にあらかじめ規定する。また、通知事象発生時の送信データ長は不定なので、１パケットの送信データの先頭と最後に必ずコマンドを付して１バイトずつ送信を行う。
図６はＳＣＦ間通信レジスタ１２ａ，１３ａの使い方を説明する図であり、同図に示すように、送信データがコマンドの場合には、送信用レジスタＥＣＯＭＲ２のビット１５のＩＮＴ、ビット８のＦＣＲをそれぞれ１にセットし、０〜７ビットのＥＣＯＮＤの上位４ビットにコマンド種別を、また、下位４ビットに詳細コードをセットする。
また、送信データがデータの場合には、ＥＣＯＭＲ２のビット１５のＩＮＴを１に、ビット８のＦＣＲを０にセットし、０〜７ビットのＥＣＯＮＤにデータを設定する。
【００２４】
図７はコマンド別送信形式を示す図であり、同図に示すように、コマンドには以下のものがあり、次の形式を持つ。
▲１▼「フェーズ通知」
自己診断中に送信されるコマンドであり、詳細コードは、自己診断フェーズを示すフェーズ番号である。
▲２▼「自己診断エラー通知」
自己診断エラーが発生したとき通知されるコマンドであり、詳細コードはコマンドシーケンス番号（後述する）である。また、送信データは、ログコードと、オペレータ操作パネル２２に設けられた液晶表示装置（以下、ＬＣＤという）の上段および下段への表示コードである。
▲３▼「機能版数通知」
ＳＣＦの機能レベル（以下、機能版数という）を通知するためのコマンドであり、「初期通知」と、ＳＣＦが非活性（ＳＣＦが動作中でない）であることを通知する「非活性通知」、ＳＣＦが活性状態であるとき通知される「活性応答」があり、詳細コードにより種別が通知される。また、送信データは自系の機能版数である。
【００２５】
▲４▼「alive message 」
両系ＳＣＦ間で一定時間毎にある決まった通知事象（この通知事象を以後、alive message という）を交換することにより、常に他系の状態を監視することができる（alive message の交換については後述する）。
図７の「alive message 」は上記したalive message を通知するためのコマンドであり、「通常通信」と「送信異常時」があり、詳細コードは、シーケンス番号である。
▲５▼「再送依頼」
受信エラーが発生したとき再送依頼を行うためのコマンドであり、詳細コードはエラー検出したシーケンス番号である。
▲６▼ 「データ開始」
データ開始を示すコマンドであり、詳細コードはシーケンス番号、送信データは送信データ＋終了コードである。
▲７▼ 「データ終了」
送信データの終了を示すコマンドであり、詳細コードは、送信データ長であり、送信データは送信したデータのサムデータである。
【００２６】
図５において、送信は次のように行われる。
(a) 送信は必ず１バイト単位とし、送信側のＳＣＦは、１バイト書き込んだ後、続けてデータを書き込む場合は、相手が読み取ったことを確認せずに、一定時間以上の間隔を空けて、データを書き込む（他系が読み取る前に、次のデータを書き込んでしまうオーバランのチェックは受信側で行う）。
(b) 受信側は、１回の割り込みが上がると受信用レジスタＥＣＯＭＲ１を一回リードして他系からの通知データを読み取る。
(c) 複数バイトのデータ送信中に、alive message 通知または通知事象が発生した場合は、送信中のデータ送信が全て完了するまで待ってから送信する。
(d) 但し、受信エラー時の再送依頼を送信する場合は、複数バイトデータの送信完了を待たずに再送依頼を送信中のデータの間に割り込んで送信する。
【００２７】
図８は通知事象発生時の送信シーケンスを示す図であり、同図に示すように、通知事象が発生すると、データ開始コマンドを送信したのち、データを１バイト目から最終バイト目まで送信する。受信側では、該受信データを記憶する。
そして、データ終了コマンドが通知されると、受信側では、終了コマンドにより送られたデータ長データと実際に受信したデータ長を比較チェックする。
さらに、送信側から１パケットの送信データの全ての和であるサムデータが送信されてくると、サムチェックを行う。
【００２８】
図９は複数バイト送信中の通知事象発生時の処理を示す図である。
同図に示すように、通知事象Ａが発生し通知事象Ａのデータを送信し、ｎバイト目まで送信したとき、alive message 等の通知事象Ｂが発生しても、このデータは送信待ちになる。一方、通知事象Ａの送信中に再送依頼による通知事象Ｃが発生すると再送依頼は即送信され、受信側でエラー処理（再送処理）が行われる。そして、通知事象Ａの送信が終了した後に、前記送信待ち状態であった通知事象Ｂが送信される。
【００２９】
図１０はＳＣＦ間通信におけるシーケンスチェック処理を示す図である。
ＳＣＦ間通信を行う際、通知事象にシーケンス番号を付与して送信し、送信側、受信側でシーケンス番号により、未受信エラーの検出や、受信エラー発生時の再送処理を実現する。また、ＳＣＦは、送信済事象とシーケンス番号を一定数記憶する送信事象管理テーブルを備えており、該テーブルにより送信履歴を管理する。
【００３０】
すなわち、図１０に示すようにデータの送信が行われる。
(a) 通知事象（発生事象、alive message ）を送信する際、通知事象毎に一連のシーケンス番号（０〜ｎ）を付与して、通知事象と一緒に他系のＳＣＦに送信する（シーケンス番号がｎを越えたら０に戻す）。
(b) 送信側は、送信履歴として送信済事象とシーケンス番号を管理テーブルに一定数記憶しておく（例えばｎ＋１個、古いデータは破棄する）。
上記送信済事象とシーケンス番号は、再送依頼時に必要であり、シーケンスエラーが発生しシーケンス番号を付して再送依頼があったとき、上記管理テーブルから該当事象を取り出し再送する。また、再送する場合にも、新たなシーケンス番号を付与して送信する。
(c) 受信側では、受信したシーケンス番号の最新の値を記憶しておく。これは、受信したシーケンス番号と、受信済シーケンス番号から受信エラーを検出するために必要であり、受信したシーケンス番号が、前回受信のシーケンス番号＋１でない場合、〔前回受信シーケンス番号＋１〕〜〔今回受信シーケンス番号−１〕までを未受信エラーとして、他系に再送依頼する。
【００３１】
例えば、図１０に示すように、通知事象Ｂ（シーケンス番号Ｎｏ．３）が未受信であり、シーケンス番号Ｎｏ．２の通知事象Ａの次にシーケンス番号Ｎｏ．４の通知事象Ｃを受信したとき、シーケンス番号Ｎｏ．３（〔Ｎｏ．２＋１〕＝Ｎｏ．３〜〔Ｎｏ．４−１〕＝Ｎｏ．３）のデータが未受信であるとして、再送依頼を行う。
送信側では、再送依頼があると、送信対象管理テーブルから該当事象（通知事象Ｂ）を取り出し、新たなシーケンス番号Ｎｏ．５を付与して再送する。
【００３２】
（２）alive message による状態監視
前記したように、上記したＳＣＦ間通信機能を用いて、両系ＳＣＦ間で一定時間毎にある決まった通知事象（この通知事象をalive message という）を交換することにより、常に他系の状態を監視することが可能となる。
すなわち、他系にalive message を送信したら、他系が一定時間alive message を保持した後、再び自系に送信されてくるような仕組みにしておくと、一定時間経ってもalive message が送信されてこなかった場合、他系に異常が発生したと判断することが可能となる。
【００３３】
具体的には、常に何れかの系でalive message の送信権（alive message 保持中の状態で、次にalive message を送信する権利）を持たせておくようにし、alive message の送信権は、他系からalive message を受信するか、一定時間（ｍ）のalive message 獲得タイマがタイムアウトしたとき獲得するようにする。
また、alive message を獲得した系は、一定時間（ｎ）の保持タイマを設定し、保持タイマがタイムアウトしたとき、他系にalive message を送信して送信権を放棄する。
上記のようにすることにより、正常時は常に何れかの系がalive message の送信権を持つようになる。そして、獲得タイマのタイムアウトによってalive message 送信権を獲得した場合は、他系がalive message を通知できない何らかの異常が発生したと判断する。
【００３４】
図１１、図１２、図１３は上記したalive message の交換制御を説明する図であり、図１１は通常時のalive message の交換制御、図１２は経路異常時のalive message の交換制御、図１３は他系の未実装またはハングアップの場合を示している。
図１１において、＃Ａ系において、保持タイマがタイムアウトすると、alive message を＃Ｂ系に送信し、alive message の送信権を放棄する。また、それと同時に獲得タイマを設定し動作を開始させる。
＃Ｂ系においては、上記alive message を受信すると、獲得タイマの動作を停止し、保持タイマを設定して動作を開始する。
そして、＃Ｂ系において、保持タイマがタイムアウトすると、alive message を＃Ａ系に送信し、alive message の送信権を放棄する。また、それと同時に獲得タイマを設定し動作を開始させる。
【００３５】
上記したalive message の交換制御において、通信経路に異常が発生すると、図１２に示すようになる。
両系で相互にalive message を交換しているとき、同図に示すように、＃Ａ系が＃Ｂ系にalive message を送信したとき経路異常が発生すると、＃Ｂ系ではalive message が受信されないので、獲得タイマがタイムアウトし、送信権を獲得する。そして、保持タイマを設定し、保持タイマがタイムアウトしたとき、＃Ａ系にalive message を送信し送信権を放棄するとともに、獲得タイマを設定して動作を開始させる。
次いで、経路異常により＃Ａ系からのalive message が再び＃Ｂ系で受信されないと、上記と同様、＃Ｂ系の獲得タイマがタイムアウトし、＃Ｂ系が送信権を獲得する。
【００３６】
なお、図１２の片系の通信経路異常の例では、他系は動作中であるが、alive message 送信権が重なることはないので、後述する共用資源の排他制御は問題なく継続される。
また、上記したalive message の交換制御において、他系のＳＣＦが未実装の場合、またはハングアップ（停止）した場合には、図１３に示すようになる。
すなわち、＃Ａ系と＃Ｂ系でalive message を交換している際、図１３に示すように、＃Ａ系のＳＣＦボードが抜かれて未実装状態になったり、あるいは、＃Ａ系のＳＣＦがハングアップした場合には、図１２と同様、＃Ｂ系ではalive message が受信されないので、獲得タイマがタイムアウトし、送信権を獲得する。そして、保持タイマを設定し、保持タイマがタイムアウトしたとき、＃Ａ系にalive message を送信し送信権を放棄するとともに、獲得タイマを設定して動作を開始させる。
次いで、経路異常により＃Ａ系からのalive message が再び＃Ｂ系で受信されないと、上記と同様、＃Ｂ系の獲得タイマがタイムアウトし、＃Ｂ系が送信権を獲得する。
【００３７】
以上のように、獲得タイマのタイムアウトによって＃Ｂ系がalive message 送信権を獲得した場合は、＃Ａ系がalive message を通知できない何らかの異常が発生したと判断することができる。
なお、前記したシーケンスエラーは、通知事象が発生しない限り検出できないが、上記のようにシーケンス番号が付与されたalive message を定期的に交換することにより、通知事象が発生しない場合であっても、問題なく通信異常を検出することができる。
【００３８】
（３）通信異常の検出と原因の切りわけ及び通信異常時の処理
（i ）通信異常の定義と原因
何らかの異常を検出し、ＳＣＦｌｉｎｋが正常に機能していない状態を通信異常とする。
通常時を含め、ＳＣＦの状態をシステム全体から見た場合、そのパターンは図１４に示すように４パターンがある。
図１４において、片系のＳＣＦ（＃Ａ系）に着目した場合、相手からの事象が受信できない場合に通信異常（同図のパターン３，４）になっていることが分かる。
ここで、送信が正常にいっていても、異常であっても送信している系の処理は変わらないため、通信異常は、相手の通信異常要因にはなるが、自系を通信異常とはしない。
また、この定義によると通信異常が発生する原因としては、大きく分けて 通信経路が異常（ハード異常）の場合と、他系が停止（ハングアップ）した場合、および、他系が未実装の場合の３通りが考えられる。
【００３９】
（ii）通信異常の検出方法
上記（i ）で述べたように、受信側は、自分が正常に受信できない事により、通信異常を検出できるが、送信側は相手が正常に受信したかどうかを自力で検出する事はできず、また、検出しても通信異常であるためにそれを確実に相手に通知できる保証はない。
以上のことから、通信異常の検出は受信側で行うものとし、送信側ではチェックは行わない。
本実施例では、図１５に示すように３つの検出機構により通信異常の検出を行う。以下の全ての原因に対する通信異常は、受信側で検出することができる。
【００４０】
(a) 受信エラーの発生
受信エラーの発生は、後述するように、パリティチェック、受信データ長チェツク、受信データサムチェック、シーケンスチェックにより検出することができる。また、その異常原因は、ハード異常（通信経路異常等）である。
(b) alive message 獲得タイムアウト
前記（２）で説明したように、alive message の交換制御により何らかの異常が発生したことを検出することができる。
この場合の異常原因は、ハード異常（通信経路断線等）、他系ＳＣＦ未実装、他系ＳＣＦハングアップ（停止）である。
(c) 異常要因検出
上記以外の異常要因としては、後述するように他系のＳＣＦ未実装検出、他系のＳＣＦ停止通知受信、他系の自己診断認識がある。
これらの異常要因は、他系ＳＣＦ未実装、他系ＳＣＦハングアップ、他系ＳＣＦ活性交換（システム動作中における他系ＳＣＦの交換）、他系自己診断中の場合である。
【００４１】
（iii) 受信エラー検出
受信エラーの検出について詳述する。
ＳＣＦファームウェア１２ｂ，１３ｂは、次のようなチェック機構を備えており、各チェック機構により受信エラーを検出し、受信エラー検出時、エラー通知（再送依頼）、返信処理（受信エラーシーケンス番号の決定）を次のように行う。
(a) パリティエラー検出
受信用レジスタＥＣＯＭＲ１の読み込み時に、ハードウェアが検出したパリティエラービットがオンの場合、パリティエラーとする。
パリティエラーを検出した場合、受信データおよび受信済データを破棄し、未受信状態とする。この時点では再送依頼は行わない。これは、次のコマンド受信時に、受信エラーを検出できるためである。
また、パリティエラーを検出した以降、次のコマンドを受信するまで、受信データは全て破棄する。そして、コマンド受信時に、受信エラー（データ長不一致、または、シーケンスエラー）となり、再送依頼が送信される。
【００４２】
(b) データ長不一致検出
通知事象を送信するとき、送信データのデータ長をコマンドに付与して送信し、受信側で受信したデータのデータ長が、コマンドで通知されたデータ長と不一致の場合に、受信データ長不一致とする。
データ長不一致を検出した時点で送信側に再送依頼を送信し、受信済データは破棄する。また、再送依頼するシーケンス番号は、受信完了シーケンス番号＋１（受信中シーケンス番号）とする。
【００４３】
(c) サムチェックエラー検出
通知事象を送信するとき、送信データの全ての和のサム値を計算して最後に送信し、受信側で受信中のデータのサム計算を行い、最後に送られてきたサム値と比較することにより受信データの正当性をチェックする。
サムチェックエラー検出時、受信した時点で送信側に再送依頼を送信し、受信済データは破棄する。また、再送依頼するシーケンス番号は、受信完了シーケンス番号＋１（受信中シーケンス番号）とする。
【００４４】
(d) シーケンスエラー検出
前記したように、受信した通知事象のシーケンス番号が、前回受信した通知事象のシーケンス番号＋１でない場合、シーケンスエラーとする。
開始コマンドを受信せずに、データを受信した場合は、そのデータを破棄し、未受信状態のままとする。これは、終了コマンド等受信時に再度エラー検出できるためである。
上記以外のシーケンスエラーを検出した場合は、検出した時点で送信側の再送依頼を送信する。また、受信済データは破棄する。
再送依頼するシーケンス番号は、受信していないシーケンス番号とする。すなわち、前記したように、〔前回までに正常に受信したシーケンス番号＋１〕〜〔今回正常に受信したシーケンス番号−１〕である。なお、未受信の事象が２つ以上ある場合は、連続して再送依頼を送信する。
【００４５】
（iv）通信異常時の処理
通信異常が発生した場合、以下の処理を行うことによって、通信異常が発生した状態でのシステム動作を保証する。
(a) 通信異常検出時の処理
▲１▼ メインプロセッサ１０へ「通信異常」を通知する。
▲２▼ メモリにエラーログを出力する。
▲３▼ オペレータ操作パネル２２のＬＣＤに異常表示をするとともに、チェックランプを点灯する。
(b) 通信異常中の処理
▲１▼ alive message 交換制御はそのまま継続する。
▲２▼ 他系への送信処理は継続する。
▲３▼ 他系からの受信事象は読み捨てる。
▲４▼ 受信エラー発生を他系に通知しない（再送依頼未送信）。
通信異常時のシステム監視事象は、それぞれのＳＣＦが独立して通知を行う。したがって、通信異常状態時に限り、共有資源で事象が発生した場合は、両系から異常通知される場合がある。
【００４６】
（v ）通信異常解除要因とその検出方法
通信異常が発生した場合、その原因がハード異常（ＳＣＦボードの異常等）とわかる場合は、交換されるまで通信異常を復旧しない処理が必要である。
また、単なる他系未実装やハングアップしただけの場合には、リセットによって復旧する必要がある。そこで、通信異常の復旧は原因別に以下の条件を満たした場合に復旧させるようにする。
【００４７】
(a) パリティエラー、通信経路異常等の復旧
ハード異常のため、自系リセットもしくは他系の活性交換完了により復旧させる。上記復旧は、次のように行われる。なお、ＳＣＦ活性交換については後で詳述する。
他系ＳＣＦ未実装から実装を認識→フェーズ通知受信→機能版数またはalive message 受信→通信異常復旧
(b) 他系ＳＣＦハングアップ又は他系ＳＣＦ未実装の復旧
他系がリセットされ、自己診断完了にて復旧する。すなわち、次のようにして復旧する。
フェーズ通知受信→機能版数又はalive message 受信→通信異常復旧
【００４８】
（４）他系ＳＣＦ未実装の検出
二重化システム通信において、一方の系の活性交換時や、他系のＳＣＦ故障時など、片系のＳＣＦのみでの運用（他系が未実装状態）を余儀なく行わなければならない場合がある。この場合は、内部的に通信異常を検出することとなるが、それが本当の通信異常なのか、他系未実装による異常なのかを見極める必要がある。
そこで、本実施例では、他系の実装／未実装状態をハード的に検出し、レジスタのビットのＯＮ／ＯＦＦでＳＣＦファームウェアに通知する仕組みを実現している。ＳＣＦファームウェアは、上記レジスタを定期的にポーリングして、監視および内部フラグの更新を行うことにより、常に他系の実装状態を把握することができる。
【００４９】
他系ＳＣＦの未実装は具体的には次のように検出する。
(a) 最初から他系未実装の場合
alive message 獲得タイマの連続タイムアウトにより、通信異常を検出するので、この時、ポーリングにより更新される上記内部フラグ（他系の実装状態を示す）を見にいき、通信異常の原因が他系のＳＣＦ未実装によるものであるかを判断する。
(b) 運用中に他系のＳＣＦが抜かれた場合
上記レジスタをポーリングすることによって、他系のＳＣＦが実装から未実装に変化した場合を検出することができるので、この時点で他系ＳＣＦ未実装による通信異常処理を行い、この後、alive message 獲得タイマの連続タイムアウトが発生しても異常処理を行わないようにする。
以上のようにすることにより、他系が未実装のままシステムを立ち上げた場合や、運用中に不当に抜かれた場合でも、通信異常でなく、適切なメッセージ（他系未実装）を外部に通知することができる。
【００５０】
（５）資源の監視と事象通知
各ＳＣＦは次のようにして各資源の監視を行い、通知事象が発生したとき、メインプロセッサに事象を通知し、また、他系のＳＣＦに通知する。
(a) 片系固有で監視可能な事象の資源の監視と事象の通知
前記図２に示した外部無停電電源装置（外部ＵＰＳ）１６、拡張筐体制御インタフェースＲＣＩ、温度センサ２０等、二重化した個々のＳＣＦのそれぞれが監視・制御する固有資源において事象が発生した場合、検出した系でメインプロセッサ１０に事象を通知する。
また、ＳＣＦ間通信機能を使用して他系のＳＣＦに情報を通知する（検出系からメインプロセッサ１０に事象通知ができない異常時に、他系ＳＣＦから代替通知させるため）。
他系のＳＣＦが通知すべき事象を、他系のＳＣＦから通知された系は、その事象を保留しておき、特に処理は行わない。
なお、上記のように、他系がメインプロセッサ１０に事象通知できないことを検出した場合は、保留していた事象、および、新たに通知された事象については、他系に代わってメインプロセッサ１０に代替通知を行う。
【００５１】
(b) 両系で監視可能な資源の監視と事象通知
メイン電源（ＰＤＵ）２５、内蔵無停電電源装置（ＵＰＳ）２４、ファン２１、オペレータ操作パネル２２等、二重化したＳＣＦそれぞれが１個の資源を監視・制御する共有資源において事象が発生した場合は、両系で同じ事象を検出することが可能である。
しかしながら、両系で事象を検出してメインプロセッサ１０に通知すると、両系から同じ事象が二重に通知されることになってしまう。また、検出回路の異常の場合で、片系でしか検出することができなかった場合は、両系のＳＣＦ間で矛盾が生ずる可能性がある。
以上のことから、共有資源については、事象を検出した時点でＳＣＦ間通信機能を使用して他系に事象を送信し、他系からも同じ事象通知がきて初めて処理を行うようにする。また、メインプロセッサ１０への通知は、あらかじめ通知担当を分けて決めておき、二重に事象が通知されないようにしておく。
なお、他系が異常状態時には、他系事象通知担当分も処理することで、システム全体としては、監視が継続されるようにする。
【００５２】
（６）通常時および通信異常時のシステム制御
二重化通信異常時は、通常時に対して以下のようなシステム制御を行うことによって、システムの動作を保証する。
（ｉ）通常時の動作
(a) 固有資源の監視／通知担当
▲１▼ それぞれの系が自分の担当の資源を監視する。
▲２▼ メインプロセッサ１０への通知は自分の担当の資源の異常を検出した場合に通知する。
(b) 共有資源の監視／通知担当
▲１▼ 共有資源は常に両系で監視する。
▲２▼ 通知担当は予めいずれかに固定されている。
▲３▼ メインプロセッサ１０への通知は自分の担当の資源の異常を検出し、且つ、他系から同じ異常を通知された場合に通知する。
【００５３】
(c) 共有資源の排他制御( オペレータ操作パネル２２のＬＣＤ表示等）
▲１▼ alive message 交換制御により、alive message 送信権を持っている時のみ、アクセス権を獲得しアクセス可能とする。
例えば、オペレータ操作パネル２２のＬＣＤ表示あるいは操作スイッチの排他制御においては、alive message 送信権を持つＳＣＦがアクセス権を持つ。
▲２▼ アクセス権（alive message 送信権）を持っていない時にアクセス要因が発生した場合は、次のアクセス権を持つまで待つ。
【００５４】
（ii）通信異常時の動作
(a) 固有資源の監視／通知担当
▲１▼ それぞれの系が自分の担当の資源を監視する。
▲２▼ メインプロセッサ１０への通知は自分の担当の資源の異常を検出した場合に通知する。
(b) 共有資源の監視／通知担当
▲１▼ 共有資源は常に両系で監視する。
▲２▼ メインプロセッサ１０への通知権は無条件で獲得する。
▲３▼ 通信異常を検出したら、他系からの異常通知を待たずにメインプロセッサ１０へ通知する。
【００５５】
(c) 共有資源の排他制御( オペレータ操作パネル２２のＬＣＤ表示等）
▲１▼ alive message 交換制御はそのまま継続し、通常時と同様alive message 送信権を持っている時のみ、アクセス可能とする。
なお、通信異常時といえども、アクセス権をいずれかに持たせるようなことはしない。これは、他系から共通資源をアクセスできなくなることを防ぐためであり、この方式によって片系のみの通信異常であれば、１００％排他制御が可能となる。また、両系が通信異常の場合でも、初期（起動直後）のalive message 送信権の獲得を両系で意識的にずらすことによって、両系のアクセス権が重なることなく、排他制御が可能となる。
▲２▼ アクセス権（alive message 送信権）を持っていない時にアクセス要因が発生した場合は、次のアクセス権を持つまで待つ。
【００５６】
（７）ＳＣＦ活性交換
二重化システムにおいて、片系が故障した場合等に、運用状態のまま故障したＳＣＦ等の交換を実現するＳＣＦ活性交換について説明する。
本実施例では以下に説明するように、システム運用状態のまま、個々のＳＣＦを交換することができ、片系の異常ではダウンしないノーストップを実現している（この運用中のＳＣＦ交換を、活性交換又は活性挿入という）。
(a) 活性交換の認識
活性交換を行うには、まず動作中の正常系ＳＣＦに対して、保守ツールにて「他系停止通知」を発行する。「他系停止通知」を受信した系は、他系がこれから活性交換されると認識し、以後、他系未実装等の異常を検出しても異常処理を行わないように、この時点で内部的に通信異常状態とする。
通信異常状態となった動作系ＳＣＦは、前記したように他系の監視範囲であった共有資源の監視／通知権を引き継ぐため、システムとして動作し続けることができる。
【００５７】
(b) 活性交換の認識（交換後）
ＳＣＦが交換され活性挿入されると、挿入された系はリセットされ、自己診断を開始し、他系に自己診断フェーズ通知を送信する。
自己診断が終了すると、メインプロセッサ１０から内部引き継ぎ情報をＳＣＦコマンドにて通知され、オンライン状態とする。
一方、通信異常で動作中であった系は、他系からの自己診断フェーズ通知を受信することにより、他系がリセット（活性交換）されたと認識し、自己診断終了後の機能版数通知（後述する）を受信することにより、通信異常状態を解除する。これによって、二重化ＳＣＦによるシステム制御が再開され、運用中の活性交換が実現する。
【００５８】
図１６は活性交換の手順を示す図であり、同図に示すように活性交換が実現される（以下の(1) 〜(11)は図１６の丸数字に対応する）。
(1) 保守ツールから、正常なＳＣＦに他系を活性交換することを通知する。（→他系停止通知の発行）
(2) 他系が上記停止通知を受信すると、他系が停止／抜かれることに対する監視異常検出を抑止する。また、内部的に通信異常状態で動作させるとともに、他系監視範囲を正常なＳＣＦが引き継ぐ。
(3) 交換ＳＣＦを抜く。この場合、他系未実装等の異常検出は行わない。
(4) 新しいＳＣＦを挿入し、リセットする。
(5) 新しいＳＣＦは自己診断を開始し、自己診断のフェーズ通知を送信する。
(6) 動作中のＳＣＦは他系のリセットを認識し、自己診断中とする。
(7) 新しいＳＣＦのタスクが起動し、挿入されＳＣＦの機能版数を動作中のＳＣＦに通知する。
【００５９】
(8) 動作中のＳＣＦは機能版数を受信し、機能版数のチェック処理を行う。そして、自系の機能版数を機能版数応答として新しいＳＣＦに通知する。さらに、動作中のＳＣＦは通信異常を復旧し、他系監視範囲であった資源の監視引き継ぎを停止する。
(9) 新しいＳＣＦは、動作中のＳＣＦから機能版数応答を受信すると、機能版数チェック処理を行い、新しいＳＣＦの正常起動を保守ツールに通知する。
(10)保守ツールは新しいＳＣＦの正常動作を認識し、ディスクに退避していたデータを読み込み、内部情報を動作側のＳＣＦから新しいＳＣＦ側に複写する。また、ＳＣＦコマンドにより動作中のＳＣＦから新しいＳＣＦへの内部情報の引き継ぎを行う。
(11)新しいＳＣＦはＳＣＦコマンドを受信し、オンライン状態に遷移する（活性交換完了）。
【００６０】
（８）ＳＣＦ活性交換後の資源の監視および事象の通知
以上のように活性交換が完了した後の固有資源および共有資源の監視／通知は次のように行われる。
(a) 固有資源の監視／通知担当
動作側の系は、自分の監視／通知担当の固有資源を引き続き監視／通知し、挿入側の系も、起動時から、自分の監視／通知担当の固有資源の監視を行うことにより、それぞれの系が自分の担当の資源を監視／通知する。
【００６１】
(b) 共有資源の監視／通知担当
動作側の系は、今までは（通信異常状態時）、異常検出すると他系からの異常通知を待たずにメインプロセッサ１０に異常通知していたが、通信異常が解除された時点で、メインプロセッサ１０への通知権はそのまま引き継ぐが、異常検出をしたとき、前記したように他系からの同じ異常通知を待ち合わせるようにする。
なお、挿入側の系は共有資源の監視は行うが、通知権を獲得しないようにすることによって、処理を簡略化することもできる。
(c) 共有資源の排他制御（オペレータ操作パネルのＬＣＤ表示等）
他系の活性挿入によって、alive message 交換制御が復活するため、共通資源の排他制御は自動的に行われるようになる。
以上のように構成することにより、ＳＣＦが後から挿入された場合でも、運用中のＳＣＦから情報を引き継ぎ、両系を矛盾なく動作させることが可能となる。
【００６２】
（９）機能版数の整合性チェックと対処
両系のＳＣＦ同時起動時、およびＳＣＦ活性挿入時に、それぞれのＳＣＦの機能版数が不一致であると、ＳＣＦ間の通信に不具合が生ずる。
そこで、機能版数の整合性をチェックし、機能版数不整合の場合、次のような対処を行う。
(a) 両系のＳＣＦ同時起動時における機能版数の整合性チェックと対処
ＳＣＦ間通信は、両系ＳＣＦが決められたコマンドインタフェースによって動作することにより成り立つが、両系ＳＣＦは二重化によってノーストップシステムを実現するため、個別に交換可能に構成されている。
ＳＣＦが交換される要因の中には、コマンドインタフェース仕様が追加・変更される場合も考えられ、両系で異なったコマンドインタフェースとなった場合、動作保証されないままに動作してしまう。
上記のような問題を防止するため、ＳＣＦ起動時にコマンドインタフェース版数（機能版数）をお互いに通知／認識しあって、機能版数が不一致の場合に、機能版数の高い方が低い方の機能レベルに落として動作させることにより、両系のコマンドインタフェースを保証する。
【００６３】
図１７は両系ＳＣＦが同時に起動された際の機能版数チェツク結果とその対処を示す図である。具体的には、次のようにして機能版数の整合性チェックと機能版数不整合の場合の対処を行う。
▲１▼ ＳＣＦが起動されて、ＳＣＦ間通信が開始される前に版数情報（版数情報問い合わせコマンドを発行）を両系ＳＣＦ間で通信し合う。
なお、機能版数情報を送信するタイミングは、自系ＳＣＦが機能された場合（機能版数通知コマンド発行）、あるいは、他系から上記機能版数通知コマンドを受信した場合（機能版数応答コマンドを発行）である。また、機能版数応答コマンドを受信した場合には、機能版数の通知を停止する。
▲２▼ 他系のＳＣＦから起動直後の機能版数を受信したら、自系で版数比較によるチェックを行うとともに、自系の機能版数情報を応答として返す。
▲３▼ 機能版数をチェックし、＃Ａ系と＃Ｂ系の機能版数が同じ場合には、問題がないので処理を行わない。また、＃Ａ系と＃Ｂ系の機能版数が異なる場合には、次のような処理を行う。
・＃Ａ系と＃Ｂ系のＳＣＦは機能版数が不一致であることを認識し、オペレータ操作パネルのＬＣＤ、コンソール等に表示することにより、機能版数の不一致をオペレータに通知する。
・機能版数が高いＳＣＦの版数機能を下げて、機能版数が低いＳＣＦに機能に合わせて動作させる。なお、機能が追加・変更された場合は、低い版数の機能がわかっているので、旧版数の機能をサポートしつつ、新機能をサポートさせる。
【００６４】
(b) ＳＣＦ活性挿入時の機能版数の整合性チェックと対処
上記(a) では、両系のＳＣＦが同時に起動しているため、いずれかの系に優先度がなく、版数の低い方に機能を合わせれば、二重化状態で動作させることが可能であった。
しかし、活性交換時には、既に動作中のＳＣＦの機能が優先されるので、それより低い版数のＳＣＦが挿入された場合、動作中のＳＣＦの機能を後から挿入された系に合わせることができない。そこで、活性交換時には、この場合の挿入を拒否し、正しいＳＣＦが挿入されるまで、挿入前の状態で動作を継続させる。
【００６５】
図１８はＳＣＦ活性挿入時の機能版数チェツク結果とその対処を示す図である。前記図１６で説明したように機能版数を通知して機能版数をチェックする。そして、図１８に示すように、＃Ａ系と＃Ｂ系の機能版数が同じ場合には、問題がないので処理を行わない。
また、＃Ａ系と＃Ｂ系の機能版数が異なる場合には、次のような処理を行う。
・既に動作中の＃Ａ系のＳＣＦより活性挿入された＃Ｂ系のＳＣＦの機能レベルが高い場合には、機能版数が不一致であることをオペレータ操作パネルのＬＣＤ、コンソール等に表示することにより、オペレータに通知し、活性挿入された＃Ｂ系のＳＣＦの機能版数を低下させ、＃Ａ系のＳＣＦの機能版数に合わせて両系で動作を継続する。
・既に動作中の＃Ａ系のＳＣＦより活性挿入された＃Ｂ系のＳＣＦの機能レベルが高い場合、既に動作中の＃Ａ系のＳＣＦの機能版数を下げることは不可能なので、＃Ｂ系ＳＣＦの活性挿入異常を通知する。また、＃Ａ系のＳＣＦは挿入前と同じ状態で動作を継続する。
【００６６】
（１０）自己診断中の監視動作および自己診断異常検出時の処理
ＳＣＦの自己診断は、自分で検出して異常となる場合と、ハングアップした場合の２つのケースが考えられる。
この２つのケースの場合、他系は相手の異常を認識する必要がある。そのため、ＳＣＦ自己診断中は、常に自分の診断フェーズを他系に通知し、他系はそのを監視することにより相手の異常を認識する。
具体的には次のように行う。
【００６７】
(a) 自己診断で異常認識した場合
他系が正常に立ち上がったのを確認してから、他系に自己診断異常発生を通知する。これは、ＳＣＦが両系同時に起動された場合、他系も自己診断中の可能性があるため、この時に自己診断異常を通知しても、他系は異常処理を行えない場合があるからである。
そこで、他系が正常に起動したことを表す機能版数通知またはalive message 通知を待ち、これを受信して初めて他系に異常を通知することにより他系は相手が異常となったことを知ることができる。
【００６８】
図１９は自己診断異常検出時の処理シーケンスを示す図である。
二重化システムに場合、自己診断を両系で同時に行うと、診断項目によっては、アクセス異常が発生することがある。そこで、本実施例では、あらかじめいずれかの系が先に自己診断を行うように決めておき、一方の自己診断が完了したら他方のＳＣＦが自己診断を開始するようにしている。
すなわち、図１９に示すように、＃Ａ系が自己診断中のとき、＃Ｂ系は自己診断アイドリング中とする。そして、＃Ａ系から初期診断終了のフェーズを貰うか、他系の初期診断中のタイムアウトを検出するまでアイドリングを続ける。
正常時には、両系の自己診断が完了した時点で、両系のＳＣＦが同時に起動されるが、図１９に示すように、＃Ａ系のＳＣＦが自己診断異常を検出した場合、この時点で他系に異常を通知しても、他系が正常動作中とは限らないので、正常に立ち上がったことを示す機能版数通知を受信して初めて、自己診断異常通知を送信する。
【００６９】
自己診断異常を検出した＃Ａ系は、＃Ｂ系にその異常のエラーログコードと、ＬＣＤ表示データを予め規定されたコマンド形式で１バイトずつ通知する。
自己診断異常通知を受けた＃Ｂ系では、＃Ａ系が異常を検出して動けないことをことを知り、全てのデータを受信するまでワーク領域にデータを格納しておき、全てのデータを受信した時点で、受信した相手の異常をエラーログ登録し、ＬＣＤ表示器等により外部に通知するとともに、片系で動作を続けられるよう適切な処理を行う。
【００７０】
(b) 自己診断中にハングアップした場合
この場合には、自己診断フェーズが通知できなくなるので、他系は自己診断フェーズのタイムアウトによって相手がハングアップしたことを認識することができる。なお、監視側は、実際に自己診断フェーズ通知を監視しているのではなく、alive message の獲得タイマの連続タイムアウトによって相手の異常を認識し、他系が一番最後に通知したデータを受信用レジスタＥＣＯＭＲ１をリードしにいくことにより調べる。そしてそれが自己診断フェーズであった場合は、その診断フェーズでハングアップしたと認識する仕組みとなっている。
【００７１】
図２０は自己診断中ハングアップ時の処理シーケンスを示す図である。
自己診断中にハングアップした場合、正常系（＃Ｂ系）が他系（＃Ａ系）自己診断中のタイムアウトを検出するところまでは前記した図１９と同じであるが、その後、機能版数の応答やalive message が送信されてこないので、図２０に示すように、＃Ｂ系のalive message 獲得タイマが連続タイムアウトし、＃Ａ系が停止したことを認識する。
ここで、受信用カウンタＥＣＯＭＲ１には一番最後に動作していた自己診断フェーズが残っているので、受信用カウンタＥＣＯＭＲ１をリードすることにより、＃Ａ系の自己診断がどこまで動作したかを知ることができる。この情報を元に、前記したように、異常をエラーログ登録し、ＬＣＤ表示器等により外部に通知するとともに、片系で動作を続けられるよう適切な処理を行う。
以上のようにすることにより、両系で自己診断を行っていた場合でも、自己診断の異常を、正常な系が立ち上がった後に必ず検出することができる。
【００７２】
【発明の効果】
以上説明したように、本発明においては、以下の効果を得ることができる。
（１）二重化ＳＣＦ間での通信処理を行えるようになるため、二重化システムの制御を行う上で、両ＳＣＦ間での処理に一貫性を持たせることができる。また、片系異常時でも適切な処理を迅速に行うことができ、ノーストップシステムの実現を容易に行うことが可能となる。
（２）共有資源の排他制御や、片系故障時の切り離し処理、他系資源の監視引き継ぎ処理を容易に行うことができる。
（３）二重化した両ＳＣＦ間で常に他系の状態を監視することができ、片系故障の対処が容易になる。
【００７３】
（４）通知事象単位の送受信データを全てシーケンス番号で管理することができ、受信エラーの検出や、受信エラー発生時の他系の通知処理および再送事象の検索処理等が容易になる。
（５）二重化した両ＳＣＦ間の通信異常を迅速に検出し、ハード異常なのか他系異常なのかを切り分けて適切な処理を行うことが可能となる。
（６）他系の未実装時に、通信異常を検出しても、ハード異常としないで、他系未実装による通信異常と認識することができる。
（７）それぞれのＳＣＦが監視している固有資源の通知事象を、自系からメインプロセッサに通知できない異常時であっても、他系から代替通知をすることができる。
（８）両系で監視している共有資源で検出した事象を、他系でも検出していることを確認した上で処理することができる。また、メインプロセッサへの通知も両系から二重に通知されることがない。
（９）二重化した両ＳＣＦ間において、一方の系に監視異常が発生した場合であっても、システムダウンとならずに動作させ続けることが可能となる。
【００７４】
（１０）システム動作中のまま、片系のＳＣＦを交換することが可能となり、片系故障時でもノーストップ／ノーダウンシステムを実現することができる。
（１１）活性挿入されたＳＣＦに対して、動作中のＳＣＦの内部情報を引き継ぐことが可能となり、あたかも、ずっと二重化状態で動いていたように動作させることができる。
（１２）二重化した両ＳＣＦ間でお互いのＳＣＦ機能レベルの自動認識ができるようになるため、機能版数が異なるままで動作することがなくなり、二重化システムの動作を常に保証することが可能となる。
（１３）活性挿入時に、機能版数がアップされたＳＣＦを挿入しても、二重化システムの動作を常に保証することが可能となる。また、オペレータによる操作ミス等のより機能版数がダウンしたＳＣＦを挿入された場合でも、そのまま動作することなく挿入拒否をすることが可能となる。
（１４）他系の自己診断の異常を迅速に検出することが可能となり、適切な処置を行うことが可能となる。
（１５）エラーログ出力およびＬＣＤ表示不可能な異常（ハングアップ）が発生した場合でも、監視している他系ＳＣＦによって異常を外部に通知することが可能となる。
【図面の簡単な説明】
【図１】本発明の原理構成図である。
【図２】本発明の実施例のシステム制御構成と監視資源を示す図である。
【図３】本発明の実施例の二重化ＳＣＦ間通信の概略図である。
【図４】本発明の実施例のＳＣＦ間通信レジスタの構成を示す図である。
【図５】ＳＣＦ間通信レジスタのアクセス方法を説明する図である。
【図６】ＳＣＦ間通信レジスタの使い方を説明する図である。
【図７】コマンド別送信形式を示す図である。
【図８】通知事象発生時の送信シーケンスを示す図である。
【図９】複数バイト送信中の通知事象発生時の処理を示す図である。
【図１０】ＳＣＦ間通信におけるシーケンスチェック処理を示す図である。
【図１１】通常時のalive message の交換制御を説明する図である。
【図１２】経路異常時のalive message の交換制御を説明する図である。
【図１３】未実装又はハングアップ時のalive message 交換制御を説明する図である。
【図１４】システム全体からみた通信異常パターンを示す図である。
【図１５】異常検出機構と異常原因を示す図である。
【図１６】ＳＣＦ活性交換の手順を示す図である。
【図１７】両系ＳＣＦの機能版数と処理を示す図（両系同時起動時）である。
【図１８】両系ＳＣＦの機能版数と処理を示す図（活性挿入時）である。
【図１９】自己診断異常検出時の処理シーケンスである。
【図２０】自己診断中ハングアップ時の処理シーケンスである。
【符号の説明】
１ メインプロセッサ
２ バス
３ａ，３ｂ 監視／制御プロセッサ
４ 通信手段
５，５ 固有資源
６ 共有資源
１０ メインプロセッサ
１１ ＳＣバス
１２，１３ ＳＣＦ
１４ 信号線（ＳＣＦＬｉｎｋ）
１５ ＲＳ２３２Ｃインタフェース
１６ 外部無停電電源装置（外部ＵＰＳ）
１７ 外部設備
１８ 拡張装置
１９ 拡張装置電源
２０ 温度センサ
２１ ファンである。
２２ オペレータ操作パネル
２３ サブ電源装置（ＰＳＵ）
２４ 内蔵無停電電源装置（ＵＰＳ）
２５ メイン電源装置（ＰＤＵ）
ＥＰＣ 外部電源制御インタフェース
ＥＤＰＣＩ 拡張装置電源制御インタフェース
ＲＣＩ 拡張装置制御インタフェース
ＥＣＯＭＲ１ 受信用レジスタ
ＥＣＯＭＲ２ 送信用レジスタ
【発明の属する技術分野】
中規模以上の計算機システムにおいては、通常、メインプロセッサとは独立して、環境、装置、電源といったシステムの監視、制御、保守の機能を担当する監視／制御プロセッサが設けられる（以下、これを必要に応じてＳＣＦ：ＳｙｓｔｅｍＣｏｎｔｒｏｌＦａｃｉｌｉｔｙと呼ぶ）。
本発明は、同一システム内に二重化された監視／制御プロセッサを持つ計算機システムに関し、特に、本発明は二重化された監視／制御プロセッサによるシステムの監視・制御方法およびシステム監視・制御装置に関するものである（以下、上記二重化監視／制御プロセッサ間の通信を必要に応じてＳＣＦ間通信またはＳＣＦＬｉｎｋと呼ぶ）。
【０００２】
【従来の技術】
従来から、資源を二重化した計算機システムが知られているが、これらのシステムにおいては、ＳＣＦ自体は一つであったため、ＳＣＦ自体が故障した場合は、システムとして動作不能（システムダウン）となった。
また、ＳＣＦ自体を二重化する試みもなされているが、ＳＣＦを二重化した場合でも、従来においては両ＳＣＦ間通信が行えなかったため、共通資源の排他制御や片系資源の故障時の動作保証が困難であった。
【０００３】
【発明が解決しようとする課題】
同一システム内で各種資源を二重化することにより、システムとしてノーダウン、ノーストップを可能とする高信頼性システムを実現することができる。
しかしながら、資源を二重化した場合、それぞれの資源をＳＣＦが監視／制御して一つのシステムの動作を実現しなければならず、また、共通資源については、各ＳＣＦ間での制御が競合しないように排他制御を行う必要があり、常に他系の状態を監視し、把握しておく必要がある。
【０００４】
本発明は上記した事情に鑑みなされたものであって、本発明の第１の目的は、二重化したＳＣＦ間での通信処理を実現可能とすることにより、両ＳＣＦ間の処理に一貫性を持たせるとともに、片系異常時でも適切な処理を迅速に行うことを可能とし、ノーストップ・システムを実現することである。
本発明の第２の目的は、共通資源の排他制御や、片系故障時の切り離し処理および他系資源の監視引き継ぎを容易にすることである。
本発明の第３の目的は、二重化した両ＳＣＦ間の通信異常を迅速に検出し、ハード異常なのか他系未実装による通信異常なのかを認識できるようにするとともに、受信エラーの検出や受信エラー発生時の他系への通知処理および再送事象の検索処理を容易にすることである。
【０００５】
本発明の第４の目的は、システム動作中のまま、片系のＳＣＦを交換することを可能とするとともに、活性挿入されたＳＣＦに対して、動作中のＳＣＦの内部情報を引き継ぐことができるようにし、あたかもずっと二重化状態で動いていたように動作をさせることである。
本発明の第５の目的は、二重化した両ＳＣＦ間でお互いの機能レベルの自動認識を可能とすることにより、機能版数が異なった状態で動作することをなくし、二重化システムの動作を常に保証することである。
本発明の第６の目的は、他系の自己診断時の異常を迅速に検出できるようにし、自己診断異常時に適切な処理を行えるようにすることである。
【０００６】
【課題を解決するための手段】
図１は本発明の原理図である。同図において、１はメインプロセッサ、２はメインプロセッサと監視／制御プロセッサ間を接続するバス、３ａ，３ｂは、監視、制御、保守等を行う監視／制御プロセッサであり、監視／制御プロセッサ３ａ，３ｂは同一の構成を有し、両系の間に通信手段４が設けられている。
５は監視／制御プロセッサ３ａ，３ｂがそれぞれ監視・制御する固有資源、６は監視／制御プロセッサ３ａ，３ｂの両方が監視・制御する共有資源である。
【０００７】
図１に示すように、本発明においては次のようにして前記課題を解決する。
（１）メインプロセッサ１とは独立して設けられたシステムの監視、制御、保守を行うための監視／制御プロセッサを二重化し、二重化された監視／制御プロセッサ３ａ，３ｂによりシステムの監視・制御を行う前記二重化された監視／制御プロセッサにより、情報処理システムの監視・制御を行う情報処理装置のシステム監視・制御方法において、監視／制御プロセッサ３ａ，３ｂ間相互で通信を行うための通信手段４を設け、前記二重化された監視／制御プロセッサのうち、送信権を有する他の監視／制御プロセッサから通知事象を受信したとき、一の監視／制御プロセッサが通知事象の送信権を獲得するステップと、前記一の監視／制御プロセッサが、他の監視／制御プロセッサへの通知事象に、シーケンス番号を付与するステップと、前記一の監視／制御プロセッサが、シーケンス番号が付与された通知事象を前記他の監視／制御プロセッサに送信するステップと、前記他の監視／制御プロセッサから受信エラーの発生を原因とする再送依頼が前記シーケンス番号を用いてなされたときに、前記他の監視／制御プロセッサからの受信したシーケンス番号が付与されている通知事象を前記他の監視／制御プロセッサに再送するステップを設ける。
【０００８】
（２）上記（１）において、通知事象の送信権の放棄を行うステップをさらに有し、前記ステップは、通知事象の送信権を獲得した一の監視／制御プロセッサが、送信権の獲得から一定時間が経過することにより保持時間タイムアウトが発生した場合に、他の監視／制御プロセッサに対して通知事象を送信することにより、前記通知事象の送信権の放棄を行う。
（３）上記（２）において、前記一の監視／制御プロセッサが、送信権を有する他の監視／制御プロセッサから通知事象の送信権を獲得するステップは、送信権を有さない一の監視／制御プロセッサにおいて、前記送信権放棄から一定時間の経過により獲得時間のタイムアウトが発生した場合に、前記一の監視／制御プロセッサが通知事象の送信権を獲得する。
【０００９】
（４）上記（３）において、エラー判定を行うステップをさらに有し、前記ステップは、前記獲得時間のタイムアウトが発生した場合に、他の監視／制御プロセッサで前記送信権を獲得した一の監視／制御プロセッサにおいてエラーが発生したものと判断するステップである。
（５）情報処理装置のシステム監視・制御装置において、メインプロセッサとは独立して設けられ、情報処理システムの監視、制御又は保守を行うための二重化された監視／制御プロセッサと、前記二重化された監視／制御プロセッサ間で、通知事象の通信を行なうための通信手段とを有し、前記二重化された監視／制御プロセッサのうち一の監視／制御プロセッサは、送信権を有する他の監視／制御プロセッサから通知事象を受信したとき通知事象の送信権を獲得し、他の監視／制御プロセッサへの通知事象にシーケンス番号を付与し、前記シーケンス番号を付与された通知事象を、他の監視／制御プロセッサに送信するとともに、前記他の監視／制御プロセッサから受信エラーの発生を原因とする再送依頼が前記シーケンス番号を用いてなされたときに、前記他の監視／制御プロセッサからの受信したシーケンス番号が付与されている通知事象を前記他の監視／制御プロセッサに再送する。
【００１０】
（６）上記（５）において、二重化された監視／制御プロセッサはそれぞれ送信権保持タイマを有し、通知事象の送信権を獲得した一の監視／制御プロセッサにおいて、前記送信権保持タイマが、送信権の獲得から一定時間の経過によりタイムアウトが発生した場合に、他の監視／制御プロセッサに対して通知事象を送信することにより、前記通知事象の送信権の放棄を行う。
【００１１】
（７）上記（６）において、二重化された監視／制御プロセッサはそれぞれ送信権獲得タイマを有し、送信権を有さない一の監視／制御プロセッサにおいて、前記送信権の放棄から一定時間の経過により、前記送信権獲得タイマにタイムアウトが発生した場合に、前記一の監視／制御プロセッサに通知事象の送信権を付与する。
【００１２】
（８）上記（７）おいて、二重化された監視／制御プロセッサはそれぞれ、前記送信権獲得タイマにおいてタイムアウトが発生した場合に、他の監視／制御プロセッサでエラーが発生したものと判断する。
【００１３】
以上のように、本発明においては、お互いの状態を把握しながらメインプロセッサに対して同じ動作を行うことができ、二重化された監視／制御プロセッサに全体として一つの動作を行わせることができる。
また、片系異常時、これを迅速に検出し、適切な処理（システムダウンしないように、正常な系で制御）を継続することが可能となる。
また、送受信した全ての事象をシーケンス番号により管理することができ、送信側では、送信した事象の記憶と、再送依頼時の再送事象の取り出しが容易となる。
さらに、受信側では、事象単位のシーケンスチェックによって、未受信事象の検出が可能となり、送信側への再送依頼もエラーとなったシーケンス番号を通知するだけでよく、処理が簡略化される。
【００１４】
さらに、一定時間、事象（ alive message) が通知されなかったことをタイマのタイムアウトにより知ることができ、タイムアウトにより他系に何らかの異常が発生したことを知ることが可能となる。
また、上記事象（ alive message) の送信権をいずれか一方の系が持つという機能を利用することにより、共通資源のアクセス権等の排他制御を行うことが可能となる。
また、通信異常を全て受信側で検出することができ、また、検出機構によって通信異常の原因の予測が可能となり、通信異常に対して適切な処理を行うことが可能となる。
また、通信異常が発生した場合、これをいち早く検出し、適切な処理を行うことによって、通信異常が発生した場合であってもシステムの動作を保証することができる。
【００１８】
【発明の実施の形態】
図２は、本発明の実施例のシステムの構成と監視資源を示す図である。同図において、１０はメインプロセッサ、１２，１３は二重化されたＳＣＦであり（ＳＣＦ１２，１３を、それぞれ＃Ａ系ＳＣＦ１２、＃Ｂ系ＳＣＦ１３という）、＃Ａ系、＃Ｂ系のＳＣＦ１２，１３は同一の構成を備えている。
上記メインプロセッサ１０と各ＳＣＦ１２，１３はＳＣバス（ＳＣＦとメインプロセッサ間通信線）１１で接続されている。
１４はＳＣＦ１２，１３をハード的に接続する信号線（ＳＣＦＬｉｎｋ）であり、後述するようにＳＣＦ間通信レジスタに接続されている。
１５はＲＳ２３２Ｃインタフェース、１６は外部無停電電源装置（外部ＵＰＳ）、１７は外部設備、ＥＰＣは外部電源制御インタフェース、１８は拡張装置、ＲＣＩは拡張装置制御インタフェース、１９は拡張装置電源、ＥＤＰＣＩは拡張装置電源制御インタフェース、２０は温度センサ、２１はファンである。
また、２２はオペレータ操作パネル、２３はサブ電源装置（ＰＳＵ）、２４は内蔵無停電電源装置（ＵＰＳ）、２５はメイン電源装置（ＰＤＵ）である。
【００１９】
図２に示すように、各ＳＣＦ１２，１３には二重化された監視資源が接続されているが、外部無停電電源装置（外部ＵＰＳ）１６、拡張筐体制御インタフェースＲＣＩ、温度センサ２０等は固有資源である。
また、メイン電源（ＰＤＵ）２５、内蔵無停電電源装置（ＵＰＳ）２４、ファン２１、オペレータ操作パネル２２等は共用資源であり、両系から監視可能であ。
それぞれのＳＣＦ１２，１３は、上記したようにＳＣバス１１によってメインプロセッサと接続されているが、両系で監視している資源の事象は、いずれかの系から一回だけ通知する必要があり、また、他系の通知担当資源の事象でも、例えば、いずれかのＳＣバスが断線した場合等には、正常な系から代替通知が行えるように構成されている。
【００２０】
次に本発明の実施例の各部の構成および動作について説明する。
（１）ＳＣＦ間通信
図３は本発明の実施例のＳＣＦ間通信の概略構成を示す図である。同図において、１０はメインプロセッサ、１１はＳＣバス、１２，１３は二重化されたＳＣＦボードである。
＃Ａ系ＳＣＦボート１２、＃Ｂ系ＳＣＦボード１３は、ＳＣＦ間通信を行うため、それぞれＳＣＦ間通信用レジスタ１２ａ，１３ａを備えており、ＳＣＦ間通信用レジスタ１２ａ，１３ａは受信用レジスタＥＣＯＭＲ１と送信用レジスタＥＣＯＭＲ２から構成されている。
＃Ａ系ＳＣＦボード１２の受信用レジスタＥＣＯＭＲ１と＃Ｂ系ＳＣＦボード１３の送信用レジスタＥＣＯＭＲ２はハード的にシリアル転送を行う信号線１４により接続されており、また、＃Ｂ系ＳＣＦボード１２の受信用レジスタＥＣＯＭＲ１と＃Ａ系ＳＣＦボード１２の送信用レジスタＥＣＯＭＲ２は、同様な信号線１４により接続されており、送信用レジスタＥＣＯＭＲ２にデータを書き込むと、他系のＳＣＦに送信され、受信用レジスタＥＣＯＭＲ１に上記データが書き込まれる。
１２ｂ，１３ｂは送受信処理を行うＳＣＦファームウエア、１２ｃ，１３ｃはＳＣＦ制御用ＣＰＵである。
【００２１】
図４は、ＳＣＦ間通信用レジスタ１２ａ，１３ａにおける受信用および送信用レジスタＥＣＯＭＲ１，ＥＣＯＭＲ２の構成を示す図である。
受信用および送信レジスタＥＣＯＭＲ１，ＥＣＯＭＲ２は同図に示すように、１６ビット構成であり、下位９ビット（ＦＣＲ，ＥＣＯＮＤ）は共通のデータ領域、ビット１５（ＩＮＴ）は割り込みに使用される。
送信用レジスタＥＣＯＭＲ２のＩＮＴビットに１を設定すると他系の受信用レジスタＥＣＯＭＲ１のＩＮＴビットに１がセットされ、その系のＳＣＦ制御用ＣＰＵに割り込みが通知される。
また、ビット１４（ＰＥＲＲ）にはパリティ異常時に１がセットされる。
すなわち、１６ビットのレジスタに１ビットのパリティがハードウェアで付加され、受信時にハードウェアでパリティチェックを行い、パリティ異常時にビット１４（ＰＥＲＲ）に１がセットされる。
【００２２】
図３、図４において、送信側のＳＣＦファームウェア１２ｂまたは１３ｂは他系への通知事象が発生すると、通知データを送信用レジスタＥＣＯＭＲ２に書き込み、ＩＮＴビットに１をセットする。
このデータは信号線１４を介して受信側のＳＣＦに送信され、受信用レジスタＥＣＯＭＲ１に書き込まれる。
受信用レジスタＥＣＯＭＲ１のＩＮＴビットに１が書き込まれると、ＳＣＦ制御用ＣＰＵに割り込みが上がり、ＣＰＵから起動されたＳＣＦファームウェア１２ｂまたは１３ｂの割り込みハンドラは受信用レジスタＥＣＯＭＲ１を読み取り、ＳＣＦ間通信が実現される。
【００２３】
図５はＳＣＦ間通信レジスタのアクセス方法を示す図である。
本実施例のＳＣＦ間通信レジスタ１２ａ，１３ａは、同図に示すように、１バイトずつのＲＥＡＤ／ＷＲＩＴＥしか行うことができない。
従って、複数バイトを送受信できるようにするため、コマンド方式によりデータ送信を行い、送信するデータ長をコマンド毎にあらかじめ規定する。また、通知事象発生時の送信データ長は不定なので、１パケットの送信データの先頭と最後に必ずコマンドを付して１バイトずつ送信を行う。
図６はＳＣＦ間通信レジスタ１２ａ，１３ａの使い方を説明する図であり、同図に示すように、送信データがコマンドの場合には、送信用レジスタＥＣＯＭＲ２のビット１５のＩＮＴ、ビット８のＦＣＲをそれぞれ１にセットし、０〜７ビットのＥＣＯＮＤの上位４ビットにコマンド種別を、また、下位４ビットに詳細コードをセットする。
また、送信データがデータの場合には、ＥＣＯＭＲ２のビット１５のＩＮＴを１に、ビット８のＦＣＲを０にセットし、０〜７ビットのＥＣＯＮＤにデータを設定する。
【００２４】
図７はコマンド別送信形式を示す図であり、同図に示すように、コマンドには以下のものがあり、次の形式を持つ。
▲１▼「フェーズ通知」
自己診断中に送信されるコマンドであり、詳細コードは、自己診断フェーズを示すフェーズ番号である。
▲２▼「自己診断エラー通知」
自己診断エラーが発生したとき通知されるコマンドであり、詳細コードはコマンドシーケンス番号（後述する）である。また、送信データは、ログコードと、オペレータ操作パネル２２に設けられた液晶表示装置（以下、ＬＣＤという）の上段および下段への表示コードである。
▲３▼「機能版数通知」
ＳＣＦの機能レベル（以下、機能版数という）を通知するためのコマンドであり、「初期通知」と、ＳＣＦが非活性（ＳＣＦが動作中でない）であることを通知する「非活性通知」、ＳＣＦが活性状態であるとき通知される「活性応答」があり、詳細コードにより種別が通知される。また、送信データは自系の機能版数である。
【００２５】
▲４▼「alive message 」
両系ＳＣＦ間で一定時間毎にある決まった通知事象（この通知事象を以後、alive message という）を交換することにより、常に他系の状態を監視することができる（alive message の交換については後述する）。
図７の「alive message 」は上記したalive message を通知するためのコマンドであり、「通常通信」と「送信異常時」があり、詳細コードは、シーケンス番号である。
▲５▼「再送依頼」
受信エラーが発生したとき再送依頼を行うためのコマンドであり、詳細コードはエラー検出したシーケンス番号である。
▲６▼ 「データ開始」
データ開始を示すコマンドであり、詳細コードはシーケンス番号、送信データは送信データ＋終了コードである。
▲７▼ 「データ終了」
送信データの終了を示すコマンドであり、詳細コードは、送信データ長であり、送信データは送信したデータのサムデータである。
【００２６】
図５において、送信は次のように行われる。
(a) 送信は必ず１バイト単位とし、送信側のＳＣＦは、１バイト書き込んだ後、続けてデータを書き込む場合は、相手が読み取ったことを確認せずに、一定時間以上の間隔を空けて、データを書き込む（他系が読み取る前に、次のデータを書き込んでしまうオーバランのチェックは受信側で行う）。
(b) 受信側は、１回の割り込みが上がると受信用レジスタＥＣＯＭＲ１を一回リードして他系からの通知データを読み取る。
(c) 複数バイトのデータ送信中に、alive message 通知または通知事象が発生した場合は、送信中のデータ送信が全て完了するまで待ってから送信する。
(d) 但し、受信エラー時の再送依頼を送信する場合は、複数バイトデータの送信完了を待たずに再送依頼を送信中のデータの間に割り込んで送信する。
【００２７】
図８は通知事象発生時の送信シーケンスを示す図であり、同図に示すように、通知事象が発生すると、データ開始コマンドを送信したのち、データを１バイト目から最終バイト目まで送信する。受信側では、該受信データを記憶する。
そして、データ終了コマンドが通知されると、受信側では、終了コマンドにより送られたデータ長データと実際に受信したデータ長を比較チェックする。
さらに、送信側から１パケットの送信データの全ての和であるサムデータが送信されてくると、サムチェックを行う。
【００２８】
図９は複数バイト送信中の通知事象発生時の処理を示す図である。
同図に示すように、通知事象Ａが発生し通知事象Ａのデータを送信し、ｎバイト目まで送信したとき、alive message 等の通知事象Ｂが発生しても、このデータは送信待ちになる。一方、通知事象Ａの送信中に再送依頼による通知事象Ｃが発生すると再送依頼は即送信され、受信側でエラー処理（再送処理）が行われる。そして、通知事象Ａの送信が終了した後に、前記送信待ち状態であった通知事象Ｂが送信される。
【００２９】
図１０はＳＣＦ間通信におけるシーケンスチェック処理を示す図である。
ＳＣＦ間通信を行う際、通知事象にシーケンス番号を付与して送信し、送信側、受信側でシーケンス番号により、未受信エラーの検出や、受信エラー発生時の再送処理を実現する。また、ＳＣＦは、送信済事象とシーケンス番号を一定数記憶する送信事象管理テーブルを備えており、該テーブルにより送信履歴を管理する。
【００３０】
すなわち、図１０に示すようにデータの送信が行われる。
(a) 通知事象（発生事象、alive message ）を送信する際、通知事象毎に一連のシーケンス番号（０〜ｎ）を付与して、通知事象と一緒に他系のＳＣＦに送信する（シーケンス番号がｎを越えたら０に戻す）。
(b) 送信側は、送信履歴として送信済事象とシーケンス番号を管理テーブルに一定数記憶しておく（例えばｎ＋１個、古いデータは破棄する）。
上記送信済事象とシーケンス番号は、再送依頼時に必要であり、シーケンスエラーが発生しシーケンス番号を付して再送依頼があったとき、上記管理テーブルから該当事象を取り出し再送する。また、再送する場合にも、新たなシーケンス番号を付与して送信する。
(c) 受信側では、受信したシーケンス番号の最新の値を記憶しておく。これは、受信したシーケンス番号と、受信済シーケンス番号から受信エラーを検出するために必要であり、受信したシーケンス番号が、前回受信のシーケンス番号＋１でない場合、〔前回受信シーケンス番号＋１〕〜〔今回受信シーケンス番号−１〕までを未受信エラーとして、他系に再送依頼する。
【００３１】
例えば、図１０に示すように、通知事象Ｂ（シーケンス番号Ｎｏ．３）が未受信であり、シーケンス番号Ｎｏ．２の通知事象Ａの次にシーケンス番号Ｎｏ．４の通知事象Ｃを受信したとき、シーケンス番号Ｎｏ．３（〔Ｎｏ．２＋１〕＝Ｎｏ．３〜〔Ｎｏ．４−１〕＝Ｎｏ．３）のデータが未受信であるとして、再送依頼を行う。
送信側では、再送依頼があると、送信対象管理テーブルから該当事象（通知事象Ｂ）を取り出し、新たなシーケンス番号Ｎｏ．５を付与して再送する。
【００３２】
（２）alive message による状態監視
前記したように、上記したＳＣＦ間通信機能を用いて、両系ＳＣＦ間で一定時間毎にある決まった通知事象（この通知事象をalive message という）を交換することにより、常に他系の状態を監視することが可能となる。
すなわち、他系にalive message を送信したら、他系が一定時間alive message を保持した後、再び自系に送信されてくるような仕組みにしておくと、一定時間経ってもalive message が送信されてこなかった場合、他系に異常が発生したと判断することが可能となる。
【００３３】
具体的には、常に何れかの系でalive message の送信権（alive message 保持中の状態で、次にalive message を送信する権利）を持たせておくようにし、alive message の送信権は、他系からalive message を受信するか、一定時間（ｍ）のalive message 獲得タイマがタイムアウトしたとき獲得するようにする。
また、alive message を獲得した系は、一定時間（ｎ）の保持タイマを設定し、保持タイマがタイムアウトしたとき、他系にalive message を送信して送信権を放棄する。
上記のようにすることにより、正常時は常に何れかの系がalive message の送信権を持つようになる。そして、獲得タイマのタイムアウトによってalive message 送信権を獲得した場合は、他系がalive message を通知できない何らかの異常が発生したと判断する。
【００３４】
図１１、図１２、図１３は上記したalive message の交換制御を説明する図であり、図１１は通常時のalive message の交換制御、図１２は経路異常時のalive message の交換制御、図１３は他系の未実装またはハングアップの場合を示している。
図１１において、＃Ａ系において、保持タイマがタイムアウトすると、alive message を＃Ｂ系に送信し、alive message の送信権を放棄する。また、それと同時に獲得タイマを設定し動作を開始させる。
＃Ｂ系においては、上記alive message を受信すると、獲得タイマの動作を停止し、保持タイマを設定して動作を開始する。
そして、＃Ｂ系において、保持タイマがタイムアウトすると、alive message を＃Ａ系に送信し、alive message の送信権を放棄する。また、それと同時に獲得タイマを設定し動作を開始させる。
【００３５】
上記したalive message の交換制御において、通信経路に異常が発生すると、図１２に示すようになる。
両系で相互にalive message を交換しているとき、同図に示すように、＃Ａ系が＃Ｂ系にalive message を送信したとき経路異常が発生すると、＃Ｂ系ではalive message が受信されないので、獲得タイマがタイムアウトし、送信権を獲得する。そして、保持タイマを設定し、保持タイマがタイムアウトしたとき、＃Ａ系にalive message を送信し送信権を放棄するとともに、獲得タイマを設定して動作を開始させる。
次いで、経路異常により＃Ａ系からのalive message が再び＃Ｂ系で受信されないと、上記と同様、＃Ｂ系の獲得タイマがタイムアウトし、＃Ｂ系が送信権を獲得する。
【００３６】
なお、図１２の片系の通信経路異常の例では、他系は動作中であるが、alive message 送信権が重なることはないので、後述する共用資源の排他制御は問題なく継続される。
また、上記したalive message の交換制御において、他系のＳＣＦが未実装の場合、またはハングアップ（停止）した場合には、図１３に示すようになる。
すなわち、＃Ａ系と＃Ｂ系でalive message を交換している際、図１３に示すように、＃Ａ系のＳＣＦボードが抜かれて未実装状態になったり、あるいは、＃Ａ系のＳＣＦがハングアップした場合には、図１２と同様、＃Ｂ系ではalive message が受信されないので、獲得タイマがタイムアウトし、送信権を獲得する。そして、保持タイマを設定し、保持タイマがタイムアウトしたとき、＃Ａ系にalive message を送信し送信権を放棄するとともに、獲得タイマを設定して動作を開始させる。
次いで、経路異常により＃Ａ系からのalive message が再び＃Ｂ系で受信されないと、上記と同様、＃Ｂ系の獲得タイマがタイムアウトし、＃Ｂ系が送信権を獲得する。
【００３７】
以上のように、獲得タイマのタイムアウトによって＃Ｂ系がalive message 送信権を獲得した場合は、＃Ａ系がalive message を通知できない何らかの異常が発生したと判断することができる。
なお、前記したシーケンスエラーは、通知事象が発生しない限り検出できないが、上記のようにシーケンス番号が付与されたalive message を定期的に交換することにより、通知事象が発生しない場合であっても、問題なく通信異常を検出することができる。
【００３８】
（３）通信異常の検出と原因の切りわけ及び通信異常時の処理
（i ）通信異常の定義と原因
何らかの異常を検出し、ＳＣＦｌｉｎｋが正常に機能していない状態を通信異常とする。
通常時を含め、ＳＣＦの状態をシステム全体から見た場合、そのパターンは図１４に示すように４パターンがある。
図１４において、片系のＳＣＦ（＃Ａ系）に着目した場合、相手からの事象が受信できない場合に通信異常（同図のパターン３，４）になっていることが分かる。
ここで、送信が正常にいっていても、異常であっても送信している系の処理は変わらないため、通信異常は、相手の通信異常要因にはなるが、自系を通信異常とはしない。
また、この定義によると通信異常が発生する原因としては、大きく分けて 通信経路が異常（ハード異常）の場合と、他系が停止（ハングアップ）した場合、および、他系が未実装の場合の３通りが考えられる。
【００３９】
（ii）通信異常の検出方法
上記（i ）で述べたように、受信側は、自分が正常に受信できない事により、通信異常を検出できるが、送信側は相手が正常に受信したかどうかを自力で検出する事はできず、また、検出しても通信異常であるためにそれを確実に相手に通知できる保証はない。
以上のことから、通信異常の検出は受信側で行うものとし、送信側ではチェックは行わない。
本実施例では、図１５に示すように３つの検出機構により通信異常の検出を行う。以下の全ての原因に対する通信異常は、受信側で検出することができる。
【００４０】
(a) 受信エラーの発生
受信エラーの発生は、後述するように、パリティチェック、受信データ長チェツク、受信データサムチェック、シーケンスチェックにより検出することができる。また、その異常原因は、ハード異常（通信経路異常等）である。
(b) alive message 獲得タイムアウト
前記（２）で説明したように、alive message の交換制御により何らかの異常が発生したことを検出することができる。
この場合の異常原因は、ハード異常（通信経路断線等）、他系ＳＣＦ未実装、他系ＳＣＦハングアップ（停止）である。
(c) 異常要因検出
上記以外の異常要因としては、後述するように他系のＳＣＦ未実装検出、他系のＳＣＦ停止通知受信、他系の自己診断認識がある。
これらの異常要因は、他系ＳＣＦ未実装、他系ＳＣＦハングアップ、他系ＳＣＦ活性交換（システム動作中における他系ＳＣＦの交換）、他系自己診断中の場合である。
【００４１】
（iii) 受信エラー検出
受信エラーの検出について詳述する。
ＳＣＦファームウェア１２ｂ，１３ｂは、次のようなチェック機構を備えており、各チェック機構により受信エラーを検出し、受信エラー検出時、エラー通知（再送依頼）、返信処理（受信エラーシーケンス番号の決定）を次のように行う。
(a) パリティエラー検出
受信用レジスタＥＣＯＭＲ１の読み込み時に、ハードウェアが検出したパリティエラービットがオンの場合、パリティエラーとする。
パリティエラーを検出した場合、受信データおよび受信済データを破棄し、未受信状態とする。この時点では再送依頼は行わない。これは、次のコマンド受信時に、受信エラーを検出できるためである。
また、パリティエラーを検出した以降、次のコマンドを受信するまで、受信データは全て破棄する。そして、コマンド受信時に、受信エラー（データ長不一致、または、シーケンスエラー）となり、再送依頼が送信される。
【００４２】
(b) データ長不一致検出
通知事象を送信するとき、送信データのデータ長をコマンドに付与して送信し、受信側で受信したデータのデータ長が、コマンドで通知されたデータ長と不一致の場合に、受信データ長不一致とする。
データ長不一致を検出した時点で送信側に再送依頼を送信し、受信済データは破棄する。また、再送依頼するシーケンス番号は、受信完了シーケンス番号＋１（受信中シーケンス番号）とする。
【００４３】
(c) サムチェックエラー検出
通知事象を送信するとき、送信データの全ての和のサム値を計算して最後に送信し、受信側で受信中のデータのサム計算を行い、最後に送られてきたサム値と比較することにより受信データの正当性をチェックする。
サムチェックエラー検出時、受信した時点で送信側に再送依頼を送信し、受信済データは破棄する。また、再送依頼するシーケンス番号は、受信完了シーケンス番号＋１（受信中シーケンス番号）とする。
【００４４】
(d) シーケンスエラー検出
前記したように、受信した通知事象のシーケンス番号が、前回受信した通知事象のシーケンス番号＋１でない場合、シーケンスエラーとする。
開始コマンドを受信せずに、データを受信した場合は、そのデータを破棄し、未受信状態のままとする。これは、終了コマンド等受信時に再度エラー検出できるためである。
上記以外のシーケンスエラーを検出した場合は、検出した時点で送信側の再送依頼を送信する。また、受信済データは破棄する。
再送依頼するシーケンス番号は、受信していないシーケンス番号とする。すなわち、前記したように、〔前回までに正常に受信したシーケンス番号＋１〕〜〔今回正常に受信したシーケンス番号−１〕である。なお、未受信の事象が２つ以上ある場合は、連続して再送依頼を送信する。
【００４５】
（iv）通信異常時の処理
通信異常が発生した場合、以下の処理を行うことによって、通信異常が発生した状態でのシステム動作を保証する。
(a) 通信異常検出時の処理
▲１▼ メインプロセッサ１０へ「通信異常」を通知する。
▲２▼ メモリにエラーログを出力する。
▲３▼ オペレータ操作パネル２２のＬＣＤに異常表示をするとともに、チェックランプを点灯する。
(b) 通信異常中の処理
▲１▼ alive message 交換制御はそのまま継続する。
▲２▼ 他系への送信処理は継続する。
▲３▼ 他系からの受信事象は読み捨てる。
▲４▼ 受信エラー発生を他系に通知しない（再送依頼未送信）。
通信異常時のシステム監視事象は、それぞれのＳＣＦが独立して通知を行う。したがって、通信異常状態時に限り、共有資源で事象が発生した場合は、両系から異常通知される場合がある。
【００４６】
（v ）通信異常解除要因とその検出方法
通信異常が発生した場合、その原因がハード異常（ＳＣＦボードの異常等）とわかる場合は、交換されるまで通信異常を復旧しない処理が必要である。
また、単なる他系未実装やハングアップしただけの場合には、リセットによって復旧する必要がある。そこで、通信異常の復旧は原因別に以下の条件を満たした場合に復旧させるようにする。
【００４７】
(a) パリティエラー、通信経路異常等の復旧
ハード異常のため、自系リセットもしくは他系の活性交換完了により復旧させる。上記復旧は、次のように行われる。なお、ＳＣＦ活性交換については後で詳述する。
他系ＳＣＦ未実装から実装を認識→フェーズ通知受信→機能版数またはalive message 受信→通信異常復旧
(b) 他系ＳＣＦハングアップ又は他系ＳＣＦ未実装の復旧
他系がリセットされ、自己診断完了にて復旧する。すなわち、次のようにして復旧する。
フェーズ通知受信→機能版数又はalive message 受信→通信異常復旧
【００４８】
（４）他系ＳＣＦ未実装の検出
二重化システム通信において、一方の系の活性交換時や、他系のＳＣＦ故障時など、片系のＳＣＦのみでの運用（他系が未実装状態）を余儀なく行わなければならない場合がある。この場合は、内部的に通信異常を検出することとなるが、それが本当の通信異常なのか、他系未実装による異常なのかを見極める必要がある。
そこで、本実施例では、他系の実装／未実装状態をハード的に検出し、レジスタのビットのＯＮ／ＯＦＦでＳＣＦファームウェアに通知する仕組みを実現している。ＳＣＦファームウェアは、上記レジスタを定期的にポーリングして、監視および内部フラグの更新を行うことにより、常に他系の実装状態を把握することができる。
【００４９】
他系ＳＣＦの未実装は具体的には次のように検出する。
(a) 最初から他系未実装の場合
alive message 獲得タイマの連続タイムアウトにより、通信異常を検出するので、この時、ポーリングにより更新される上記内部フラグ（他系の実装状態を示す）を見にいき、通信異常の原因が他系のＳＣＦ未実装によるものであるかを判断する。
(b) 運用中に他系のＳＣＦが抜かれた場合
上記レジスタをポーリングすることによって、他系のＳＣＦが実装から未実装に変化した場合を検出することができるので、この時点で他系ＳＣＦ未実装による通信異常処理を行い、この後、alive message 獲得タイマの連続タイムアウトが発生しても異常処理を行わないようにする。
以上のようにすることにより、他系が未実装のままシステムを立ち上げた場合や、運用中に不当に抜かれた場合でも、通信異常でなく、適切なメッセージ（他系未実装）を外部に通知することができる。
【００５０】
（５）資源の監視と事象通知
各ＳＣＦは次のようにして各資源の監視を行い、通知事象が発生したとき、メインプロセッサに事象を通知し、また、他系のＳＣＦに通知する。
(a) 片系固有で監視可能な事象の資源の監視と事象の通知
前記図２に示した外部無停電電源装置（外部ＵＰＳ）１６、拡張筐体制御インタフェースＲＣＩ、温度センサ２０等、二重化した個々のＳＣＦのそれぞれが監視・制御する固有資源において事象が発生した場合、検出した系でメインプロセッサ１０に事象を通知する。
また、ＳＣＦ間通信機能を使用して他系のＳＣＦに情報を通知する（検出系からメインプロセッサ１０に事象通知ができない異常時に、他系ＳＣＦから代替通知させるため）。
他系のＳＣＦが通知すべき事象を、他系のＳＣＦから通知された系は、その事象を保留しておき、特に処理は行わない。
なお、上記のように、他系がメインプロセッサ１０に事象通知できないことを検出した場合は、保留していた事象、および、新たに通知された事象については、他系に代わってメインプロセッサ１０に代替通知を行う。
【００５１】
(b) 両系で監視可能な資源の監視と事象通知
メイン電源（ＰＤＵ）２５、内蔵無停電電源装置（ＵＰＳ）２４、ファン２１、オペレータ操作パネル２２等、二重化したＳＣＦそれぞれが１個の資源を監視・制御する共有資源において事象が発生した場合は、両系で同じ事象を検出することが可能である。
しかしながら、両系で事象を検出してメインプロセッサ１０に通知すると、両系から同じ事象が二重に通知されることになってしまう。また、検出回路の異常の場合で、片系でしか検出することができなかった場合は、両系のＳＣＦ間で矛盾が生ずる可能性がある。
以上のことから、共有資源については、事象を検出した時点でＳＣＦ間通信機能を使用して他系に事象を送信し、他系からも同じ事象通知がきて初めて処理を行うようにする。また、メインプロセッサ１０への通知は、あらかじめ通知担当を分けて決めておき、二重に事象が通知されないようにしておく。
なお、他系が異常状態時には、他系事象通知担当分も処理することで、システム全体としては、監視が継続されるようにする。
【００５２】
（６）通常時および通信異常時のシステム制御
二重化通信異常時は、通常時に対して以下のようなシステム制御を行うことによって、システムの動作を保証する。
（ｉ）通常時の動作
(a) 固有資源の監視／通知担当
▲１▼ それぞれの系が自分の担当の資源を監視する。
▲２▼ メインプロセッサ１０への通知は自分の担当の資源の異常を検出した場合に通知する。
(b) 共有資源の監視／通知担当
▲１▼ 共有資源は常に両系で監視する。
▲２▼ 通知担当は予めいずれかに固定されている。
▲３▼ メインプロセッサ１０への通知は自分の担当の資源の異常を検出し、且つ、他系から同じ異常を通知された場合に通知する。
【００５３】
(c) 共有資源の排他制御( オペレータ操作パネル２２のＬＣＤ表示等）
▲１▼ alive message 交換制御により、alive message 送信権を持っている時のみ、アクセス権を獲得しアクセス可能とする。
例えば、オペレータ操作パネル２２のＬＣＤ表示あるいは操作スイッチの排他制御においては、alive message 送信権を持つＳＣＦがアクセス権を持つ。
▲２▼ アクセス権（alive message 送信権）を持っていない時にアクセス要因が発生した場合は、次のアクセス権を持つまで待つ。
【００５４】
（ii）通信異常時の動作
(a) 固有資源の監視／通知担当
▲１▼ それぞれの系が自分の担当の資源を監視する。
▲２▼ メインプロセッサ１０への通知は自分の担当の資源の異常を検出した場合に通知する。
(b) 共有資源の監視／通知担当
▲１▼ 共有資源は常に両系で監視する。
▲２▼ メインプロセッサ１０への通知権は無条件で獲得する。
▲３▼ 通信異常を検出したら、他系からの異常通知を待たずにメインプロセッサ１０へ通知する。
【００５５】
(c) 共有資源の排他制御( オペレータ操作パネル２２のＬＣＤ表示等）
▲１▼ alive message 交換制御はそのまま継続し、通常時と同様alive message 送信権を持っている時のみ、アクセス可能とする。
なお、通信異常時といえども、アクセス権をいずれかに持たせるようなことはしない。これは、他系から共通資源をアクセスできなくなることを防ぐためであり、この方式によって片系のみの通信異常であれば、１００％排他制御が可能となる。また、両系が通信異常の場合でも、初期（起動直後）のalive message 送信権の獲得を両系で意識的にずらすことによって、両系のアクセス権が重なることなく、排他制御が可能となる。
▲２▼ アクセス権（alive message 送信権）を持っていない時にアクセス要因が発生した場合は、次のアクセス権を持つまで待つ。
【００５６】
（７）ＳＣＦ活性交換
二重化システムにおいて、片系が故障した場合等に、運用状態のまま故障したＳＣＦ等の交換を実現するＳＣＦ活性交換について説明する。
本実施例では以下に説明するように、システム運用状態のまま、個々のＳＣＦを交換することができ、片系の異常ではダウンしないノーストップを実現している（この運用中のＳＣＦ交換を、活性交換又は活性挿入という）。
(a) 活性交換の認識
活性交換を行うには、まず動作中の正常系ＳＣＦに対して、保守ツールにて「他系停止通知」を発行する。「他系停止通知」を受信した系は、他系がこれから活性交換されると認識し、以後、他系未実装等の異常を検出しても異常処理を行わないように、この時点で内部的に通信異常状態とする。
通信異常状態となった動作系ＳＣＦは、前記したように他系の監視範囲であった共有資源の監視／通知権を引き継ぐため、システムとして動作し続けることができる。
【００５７】
(b) 活性交換の認識（交換後）
ＳＣＦが交換され活性挿入されると、挿入された系はリセットされ、自己診断を開始し、他系に自己診断フェーズ通知を送信する。
自己診断が終了すると、メインプロセッサ１０から内部引き継ぎ情報をＳＣＦコマンドにて通知され、オンライン状態とする。
一方、通信異常で動作中であった系は、他系からの自己診断フェーズ通知を受信することにより、他系がリセット（活性交換）されたと認識し、自己診断終了後の機能版数通知（後述する）を受信することにより、通信異常状態を解除する。これによって、二重化ＳＣＦによるシステム制御が再開され、運用中の活性交換が実現する。
【００５８】
図１６は活性交換の手順を示す図であり、同図に示すように活性交換が実現される（以下の(1) 〜(11)は図１６の丸数字に対応する）。
(1) 保守ツールから、正常なＳＣＦに他系を活性交換することを通知する。（→他系停止通知の発行）
(2) 他系が上記停止通知を受信すると、他系が停止／抜かれることに対する監視異常検出を抑止する。また、内部的に通信異常状態で動作させるとともに、他系監視範囲を正常なＳＣＦが引き継ぐ。
(3) 交換ＳＣＦを抜く。この場合、他系未実装等の異常検出は行わない。
(4) 新しいＳＣＦを挿入し、リセットする。
(5) 新しいＳＣＦは自己診断を開始し、自己診断のフェーズ通知を送信する。
(6) 動作中のＳＣＦは他系のリセットを認識し、自己診断中とする。
(7) 新しいＳＣＦのタスクが起動し、挿入されＳＣＦの機能版数を動作中のＳＣＦに通知する。
【００５９】
(8) 動作中のＳＣＦは機能版数を受信し、機能版数のチェック処理を行う。そして、自系の機能版数を機能版数応答として新しいＳＣＦに通知する。さらに、動作中のＳＣＦは通信異常を復旧し、他系監視範囲であった資源の監視引き継ぎを停止する。
(9) 新しいＳＣＦは、動作中のＳＣＦから機能版数応答を受信すると、機能版数チェック処理を行い、新しいＳＣＦの正常起動を保守ツールに通知する。
(10)保守ツールは新しいＳＣＦの正常動作を認識し、ディスクに退避していたデータを読み込み、内部情報を動作側のＳＣＦから新しいＳＣＦ側に複写する。また、ＳＣＦコマンドにより動作中のＳＣＦから新しいＳＣＦへの内部情報の引き継ぎを行う。
(11)新しいＳＣＦはＳＣＦコマンドを受信し、オンライン状態に遷移する（活性交換完了）。
【００６０】
（８）ＳＣＦ活性交換後の資源の監視および事象の通知
以上のように活性交換が完了した後の固有資源および共有資源の監視／通知は次のように行われる。
(a) 固有資源の監視／通知担当
動作側の系は、自分の監視／通知担当の固有資源を引き続き監視／通知し、挿入側の系も、起動時から、自分の監視／通知担当の固有資源の監視を行うことにより、それぞれの系が自分の担当の資源を監視／通知する。
【００６１】
(b) 共有資源の監視／通知担当
動作側の系は、今までは（通信異常状態時）、異常検出すると他系からの異常通知を待たずにメインプロセッサ１０に異常通知していたが、通信異常が解除された時点で、メインプロセッサ１０への通知権はそのまま引き継ぐが、異常検出をしたとき、前記したように他系からの同じ異常通知を待ち合わせるようにする。
なお、挿入側の系は共有資源の監視は行うが、通知権を獲得しないようにすることによって、処理を簡略化することもできる。
(c) 共有資源の排他制御（オペレータ操作パネルのＬＣＤ表示等）
他系の活性挿入によって、alive message 交換制御が復活するため、共通資源の排他制御は自動的に行われるようになる。
以上のように構成することにより、ＳＣＦが後から挿入された場合でも、運用中のＳＣＦから情報を引き継ぎ、両系を矛盾なく動作させることが可能となる。
【００６２】
（９）機能版数の整合性チェックと対処
両系のＳＣＦ同時起動時、およびＳＣＦ活性挿入時に、それぞれのＳＣＦの機能版数が不一致であると、ＳＣＦ間の通信に不具合が生ずる。
そこで、機能版数の整合性をチェックし、機能版数不整合の場合、次のような対処を行う。
(a) 両系のＳＣＦ同時起動時における機能版数の整合性チェックと対処
ＳＣＦ間通信は、両系ＳＣＦが決められたコマンドインタフェースによって動作することにより成り立つが、両系ＳＣＦは二重化によってノーストップシステムを実現するため、個別に交換可能に構成されている。
ＳＣＦが交換される要因の中には、コマンドインタフェース仕様が追加・変更される場合も考えられ、両系で異なったコマンドインタフェースとなった場合、動作保証されないままに動作してしまう。
上記のような問題を防止するため、ＳＣＦ起動時にコマンドインタフェース版数（機能版数）をお互いに通知／認識しあって、機能版数が不一致の場合に、機能版数の高い方が低い方の機能レベルに落として動作させることにより、両系のコマンドインタフェースを保証する。
【００６３】
図１７は両系ＳＣＦが同時に起動された際の機能版数チェツク結果とその対処を示す図である。具体的には、次のようにして機能版数の整合性チェックと機能版数不整合の場合の対処を行う。
▲１▼ ＳＣＦが起動されて、ＳＣＦ間通信が開始される前に版数情報（版数情報問い合わせコマンドを発行）を両系ＳＣＦ間で通信し合う。
なお、機能版数情報を送信するタイミングは、自系ＳＣＦが機能された場合（機能版数通知コマンド発行）、あるいは、他系から上記機能版数通知コマンドを受信した場合（機能版数応答コマンドを発行）である。また、機能版数応答コマンドを受信した場合には、機能版数の通知を停止する。
▲２▼ 他系のＳＣＦから起動直後の機能版数を受信したら、自系で版数比較によるチェックを行うとともに、自系の機能版数情報を応答として返す。
▲３▼ 機能版数をチェックし、＃Ａ系と＃Ｂ系の機能版数が同じ場合には、問題がないので処理を行わない。また、＃Ａ系と＃Ｂ系の機能版数が異なる場合には、次のような処理を行う。
・＃Ａ系と＃Ｂ系のＳＣＦは機能版数が不一致であることを認識し、オペレータ操作パネルのＬＣＤ、コンソール等に表示することにより、機能版数の不一致をオペレータに通知する。
・機能版数が高いＳＣＦの版数機能を下げて、機能版数が低いＳＣＦに機能に合わせて動作させる。なお、機能が追加・変更された場合は、低い版数の機能がわかっているので、旧版数の機能をサポートしつつ、新機能をサポートさせる。
【００６４】
(b) ＳＣＦ活性挿入時の機能版数の整合性チェックと対処
上記(a) では、両系のＳＣＦが同時に起動しているため、いずれかの系に優先度がなく、版数の低い方に機能を合わせれば、二重化状態で動作させることが可能であった。
しかし、活性交換時には、既に動作中のＳＣＦの機能が優先されるので、それより低い版数のＳＣＦが挿入された場合、動作中のＳＣＦの機能を後から挿入された系に合わせることができない。そこで、活性交換時には、この場合の挿入を拒否し、正しいＳＣＦが挿入されるまで、挿入前の状態で動作を継続させる。
【００６５】
図１８はＳＣＦ活性挿入時の機能版数チェツク結果とその対処を示す図である。前記図１６で説明したように機能版数を通知して機能版数をチェックする。そして、図１８に示すように、＃Ａ系と＃Ｂ系の機能版数が同じ場合には、問題がないので処理を行わない。
また、＃Ａ系と＃Ｂ系の機能版数が異なる場合には、次のような処理を行う。
・既に動作中の＃Ａ系のＳＣＦより活性挿入された＃Ｂ系のＳＣＦの機能レベルが高い場合には、機能版数が不一致であることをオペレータ操作パネルのＬＣＤ、コンソール等に表示することにより、オペレータに通知し、活性挿入された＃Ｂ系のＳＣＦの機能版数を低下させ、＃Ａ系のＳＣＦの機能版数に合わせて両系で動作を継続する。
・既に動作中の＃Ａ系のＳＣＦより活性挿入された＃Ｂ系のＳＣＦの機能レベルが高い場合、既に動作中の＃Ａ系のＳＣＦの機能版数を下げることは不可能なので、＃Ｂ系ＳＣＦの活性挿入異常を通知する。また、＃Ａ系のＳＣＦは挿入前と同じ状態で動作を継続する。
【００６６】
（１０）自己診断中の監視動作および自己診断異常検出時の処理
ＳＣＦの自己診断は、自分で検出して異常となる場合と、ハングアップした場合の２つのケースが考えられる。
この２つのケースの場合、他系は相手の異常を認識する必要がある。そのため、ＳＣＦ自己診断中は、常に自分の診断フェーズを他系に通知し、他系はそのを監視することにより相手の異常を認識する。
具体的には次のように行う。
【００６７】
(a) 自己診断で異常認識した場合
他系が正常に立ち上がったのを確認してから、他系に自己診断異常発生を通知する。これは、ＳＣＦが両系同時に起動された場合、他系も自己診断中の可能性があるため、この時に自己診断異常を通知しても、他系は異常処理を行えない場合があるからである。
そこで、他系が正常に起動したことを表す機能版数通知またはalive message 通知を待ち、これを受信して初めて他系に異常を通知することにより他系は相手が異常となったことを知ることができる。
【００６８】
図１９は自己診断異常検出時の処理シーケンスを示す図である。
二重化システムに場合、自己診断を両系で同時に行うと、診断項目によっては、アクセス異常が発生することがある。そこで、本実施例では、あらかじめいずれかの系が先に自己診断を行うように決めておき、一方の自己診断が完了したら他方のＳＣＦが自己診断を開始するようにしている。
すなわち、図１９に示すように、＃Ａ系が自己診断中のとき、＃Ｂ系は自己診断アイドリング中とする。そして、＃Ａ系から初期診断終了のフェーズを貰うか、他系の初期診断中のタイムアウトを検出するまでアイドリングを続ける。
正常時には、両系の自己診断が完了した時点で、両系のＳＣＦが同時に起動されるが、図１９に示すように、＃Ａ系のＳＣＦが自己診断異常を検出した場合、この時点で他系に異常を通知しても、他系が正常動作中とは限らないので、正常に立ち上がったことを示す機能版数通知を受信して初めて、自己診断異常通知を送信する。
【００６９】
自己診断異常を検出した＃Ａ系は、＃Ｂ系にその異常のエラーログコードと、ＬＣＤ表示データを予め規定されたコマンド形式で１バイトずつ通知する。
自己診断異常通知を受けた＃Ｂ系では、＃Ａ系が異常を検出して動けないことをことを知り、全てのデータを受信するまでワーク領域にデータを格納しておき、全てのデータを受信した時点で、受信した相手の異常をエラーログ登録し、ＬＣＤ表示器等により外部に通知するとともに、片系で動作を続けられるよう適切な処理を行う。
【００７０】
(b) 自己診断中にハングアップした場合
この場合には、自己診断フェーズが通知できなくなるので、他系は自己診断フェーズのタイムアウトによって相手がハングアップしたことを認識することができる。なお、監視側は、実際に自己診断フェーズ通知を監視しているのではなく、alive message の獲得タイマの連続タイムアウトによって相手の異常を認識し、他系が一番最後に通知したデータを受信用レジスタＥＣＯＭＲ１をリードしにいくことにより調べる。そしてそれが自己診断フェーズであった場合は、その診断フェーズでハングアップしたと認識する仕組みとなっている。
【００７１】
図２０は自己診断中ハングアップ時の処理シーケンスを示す図である。
自己診断中にハングアップした場合、正常系（＃Ｂ系）が他系（＃Ａ系）自己診断中のタイムアウトを検出するところまでは前記した図１９と同じであるが、その後、機能版数の応答やalive message が送信されてこないので、図２０に示すように、＃Ｂ系のalive message 獲得タイマが連続タイムアウトし、＃Ａ系が停止したことを認識する。
ここで、受信用カウンタＥＣＯＭＲ１には一番最後に動作していた自己診断フェーズが残っているので、受信用カウンタＥＣＯＭＲ１をリードすることにより、＃Ａ系の自己診断がどこまで動作したかを知ることができる。この情報を元に、前記したように、異常をエラーログ登録し、ＬＣＤ表示器等により外部に通知するとともに、片系で動作を続けられるよう適切な処理を行う。
以上のようにすることにより、両系で自己診断を行っていた場合でも、自己診断の異常を、正常な系が立ち上がった後に必ず検出することができる。
【００７２】
【発明の効果】
以上説明したように、本発明においては、以下の効果を得ることができる。
（１）二重化ＳＣＦ間での通信処理を行えるようになるため、二重化システムの制御を行う上で、両ＳＣＦ間での処理に一貫性を持たせることができる。また、片系異常時でも適切な処理を迅速に行うことができ、ノーストップシステムの実現を容易に行うことが可能となる。
（２）共有資源の排他制御や、片系故障時の切り離し処理、他系資源の監視引き継ぎ処理を容易に行うことができる。
（３）二重化した両ＳＣＦ間で常に他系の状態を監視することができ、片系故障の対処が容易になる。
【００７３】
（４）通知事象単位の送受信データを全てシーケンス番号で管理することができ、受信エラーの検出や、受信エラー発生時の他系の通知処理および再送事象の検索処理等が容易になる。
（５）二重化した両ＳＣＦ間の通信異常を迅速に検出し、ハード異常なのか他系異常なのかを切り分けて適切な処理を行うことが可能となる。
（６）他系の未実装時に、通信異常を検出しても、ハード異常としないで、他系未実装による通信異常と認識することができる。
（７）それぞれのＳＣＦが監視している固有資源の通知事象を、自系からメインプロセッサに通知できない異常時であっても、他系から代替通知をすることができる。
（８）両系で監視している共有資源で検出した事象を、他系でも検出していることを確認した上で処理することができる。また、メインプロセッサへの通知も両系から二重に通知されることがない。
（９）二重化した両ＳＣＦ間において、一方の系に監視異常が発生した場合であっても、システムダウンとならずに動作させ続けることが可能となる。
【００７４】
（１０）システム動作中のまま、片系のＳＣＦを交換することが可能となり、片系故障時でもノーストップ／ノーダウンシステムを実現することができる。
（１１）活性挿入されたＳＣＦに対して、動作中のＳＣＦの内部情報を引き継ぐことが可能となり、あたかも、ずっと二重化状態で動いていたように動作させることができる。
（１２）二重化した両ＳＣＦ間でお互いのＳＣＦ機能レベルの自動認識ができるようになるため、機能版数が異なるままで動作することがなくなり、二重化システムの動作を常に保証することが可能となる。
（１３）活性挿入時に、機能版数がアップされたＳＣＦを挿入しても、二重化システムの動作を常に保証することが可能となる。また、オペレータによる操作ミス等のより機能版数がダウンしたＳＣＦを挿入された場合でも、そのまま動作することなく挿入拒否をすることが可能となる。
（１４）他系の自己診断の異常を迅速に検出することが可能となり、適切な処置を行うことが可能となる。
（１５）エラーログ出力およびＬＣＤ表示不可能な異常（ハングアップ）が発生した場合でも、監視している他系ＳＣＦによって異常を外部に通知することが可能となる。
【図面の簡単な説明】
【図１】本発明の原理構成図である。
【図２】本発明の実施例のシステム制御構成と監視資源を示す図である。
【図３】本発明の実施例の二重化ＳＣＦ間通信の概略図である。
【図４】本発明の実施例のＳＣＦ間通信レジスタの構成を示す図である。
【図５】ＳＣＦ間通信レジスタのアクセス方法を説明する図である。
【図６】ＳＣＦ間通信レジスタの使い方を説明する図である。
【図７】コマンド別送信形式を示す図である。
【図８】通知事象発生時の送信シーケンスを示す図である。
【図９】複数バイト送信中の通知事象発生時の処理を示す図である。
【図１０】ＳＣＦ間通信におけるシーケンスチェック処理を示す図である。
【図１１】通常時のalive message の交換制御を説明する図である。
【図１２】経路異常時のalive message の交換制御を説明する図である。
【図１３】未実装又はハングアップ時のalive message 交換制御を説明する図である。
【図１４】システム全体からみた通信異常パターンを示す図である。
【図１５】異常検出機構と異常原因を示す図である。
【図１６】ＳＣＦ活性交換の手順を示す図である。
【図１７】両系ＳＣＦの機能版数と処理を示す図（両系同時起動時）である。
【図１８】両系ＳＣＦの機能版数と処理を示す図（活性挿入時）である。
【図１９】自己診断異常検出時の処理シーケンスである。
【図２０】自己診断中ハングアップ時の処理シーケンスである。
【符号の説明】
１ メインプロセッサ
２ バス
３ａ，３ｂ 監視／制御プロセッサ
４ 通信手段
５，５ 固有資源
６ 共有資源
１０ メインプロセッサ
１１ ＳＣバス
１２，１３ ＳＣＦ
１４ 信号線（ＳＣＦＬｉｎｋ）
１５ ＲＳ２３２Ｃインタフェース
１６ 外部無停電電源装置（外部ＵＰＳ）
１７ 外部設備
１８ 拡張装置
１９ 拡張装置電源
２０ 温度センサ
２１ ファンである。
２２ オペレータ操作パネル
２３ サブ電源装置（ＰＳＵ）
２４ 内蔵無停電電源装置（ＵＰＳ）
２５ メイン電源装置（ＰＤＵ）
ＥＰＣ 外部電源制御インタフェース
ＥＤＰＣＩ 拡張装置電源制御インタフェース
ＲＣＩ 拡張装置制御インタフェース
ＥＣＯＭＲ１ 受信用レジスタ
ＥＣＯＭＲ２ 送信用レジスタ
Claims (8)
- メインプロセッサとは独立して設けられ、情報処理システムの監視、制御又は保守を行うための監視／制御プロセッサを二重化するとともに、前記監視／制御プロセッサ間で、通知事象の通信を行なうための通信手段を設け、
前記二重化された監視／制御プロセッサにより、情報処理システムの監視・制御を行う情報処理装置のシステム監視・制御方法であって、
前記二重化された監視／制御プロセッサのうち、送信権を有する他の監視／制御プロセッサから通知事象を受信したとき、一の監視／制御プロセッサが通知事象の送信権を獲得するステップと、
前記一の監視／制御プロセッサが、他の監視／制御プロセッサへの通知事象に、シーケンス番号を付与するステップと、
前記一の監視／制御プロセッサが、シーケンス番号が付与された通知事象を前記他の監視／制御プロセッサに送信するステップと、
前記他の監視／制御プロセッサから受信エラーの発生を原因とする再送依頼が前記シーケンス番号を用いてなされたときに、前記他の監視／制御プロセッサからの受信したシーケンス番号が付与されている通知事象を前記他の監視／制御プロセッサに再送するステップと、
を有することを特徴とする情報処理装置のシステム監視・制御方法。 - 前記システム監視／制御方法は、通知事象の送信権の放棄を行うステップをさらに有し、
前記ステップは、通知事象の送信権を獲得した一の監視／制御プロセッサが、
前記送信権の獲得から一定時間が経過することにより保持時間タイムアウトが発生した場合に、他の監視／制御プロセッサに対して通知事象を送信することにより、前記通知事象の送信権の放棄を行うステップである
ことを特徴とする請求項１記載の情報処理装置のシステム監視・制御方法。 - 前記一の監視／制御プロセッサが、送信権を有する他の監視／制御プロセッサから通知事象の送信権を獲得するステップは、
送信権を有さない一の監視／制御プロセッサにおいて、前記送信権放棄から一定時間の経過により獲得時間のタイムアウトが発生した場合に、前記一の監視／制御プロセッサが通知事象の送信権を獲得するステップである
ことを特徴とする請求項２記載の情報処理装置のシステム監視・制御方法。 - 前記システム監視・制御方法は、エラー判定を行うステップをさらに有し、
前記ステップは、前記獲得時間のタイムアウトが発生した場合に、他の監視／制御プロセッサで前記送信権を獲得した一の監視／制御プロセッサにおいてエラーが発生したものと判断するステップである
ことを特徴とする請求項３に記載の情報処理装置のシステム監視・制御方法。 - メインプロセッサとは独立して設けられ、情報処理システムの監視、制御又は保守を行うための二重化された監視／制御プロセッサと、
前記二重化された監視／制御プロセッサ間で、通知事象の通信を行なうための通信手段とを有し、
前記二重化された監視／制御プロセッサのうち、一の監視／制御プロセッサは、送信権を有する他の監視／制御プロセッサから通知事象を受信したとき通知事象の送信権を獲得し、他の監視／制御プロセッサへの通知事象にシーケンス番号を付与し、前記シーケンス番号が付与された通知事象を、他の監視／制御プロセッサに送信するとともに、前記他の監視／制御プロセッサから受信エラーの発生を原因とする再送依頼が前記シーケンス番号 を用いてなされたときに、前記他の監視／制御プロセッサからの受信したシーケンス番号が付与されている通知事象を前記他の監視／制御プロセッサに再送することを特徴とする情報処理装置のシステム監視・制御装置。 - 前記二重化された監視／制御プロセッサはそれぞれ送信権保持タイマを有し、
通知事象の送信権を獲得した一の監視／制御プロセッサにおいて、前記送信権保持タイマが、前記送信権獲得から一定時間の経過によりタイムアウトが発生した場合に、他の監視／制御プロセッサに対して通知事象を送信することにより、前記通知事象の送信権の放棄を行う
ことを特徴とする請求項５記載の情報処理装置のシステム監視・制御装置。 - 前記二重化された監視／制御プロセッサはそれぞれ送信権獲得タイマを有し、
送信権を有さない一の監視／制御プロセッサにおいて、前記送信権の放棄から一定時間の経過により、前記送信権獲得タイマにタイムアウトが発生した場合に、前記一の監視／制御プロセッサに通知事象の送信権を付与する
ことを特徴とする請求項６記載の情報処理装置のシステム監視・制御装置。 - 前記二重化された監視／制御プロセッサはそれぞれ、前記送信権獲得タイマにおいてタイムアウトが発生した場合に、他の監視／制御プロセッサにおいてエラーが発生したものと判断することを特徴とする請求項７に記載の情報処理装置のシステム監視・制御装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP31079596A JP3942216B2 (ja) | 1996-11-21 | 1996-11-21 | 二重化された監視／制御プロセッサによるシステム監視・制御方法およびシステム監視・制御装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP31079596A JP3942216B2 (ja) | 1996-11-21 | 1996-11-21 | 二重化された監視／制御プロセッサによるシステム監視・制御方法およびシステム監視・制御装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH10154085A JPH10154085A (ja) | 1998-06-09 |
| JP3942216B2 true JP3942216B2 (ja) | 2007-07-11 |
Family
ID=18009545
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP31079596A Expired - Lifetime JP3942216B2 (ja) | 1996-11-21 | 1996-11-21 | 二重化された監視／制御プロセッサによるシステム監視・制御方法およびシステム監視・制御装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3942216B2 (ja) |
Families Citing this family (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100464490B1 (ko) * | 2000-12-22 | 2004-12-31 | 엘지전자 주식회사 | 이중화 장치의 탈/실장 관리장치 |
| JP4492035B2 (ja) | 2003-04-21 | 2010-06-30 | 日本電気株式会社 | データ処理装置 |
| JP4495015B2 (ja) * | 2005-03-16 | 2010-06-30 | 富士通株式会社 | システム管理装置、情報処理装置およびシステム管理装置冗長化方法 |
| WO2008023791A1 (en) * | 2006-08-25 | 2008-02-28 | Panasonic Corporation | Wireless transmitting apparatus, wireless receiving apparatus and wireless communication method |
| JP5131194B2 (ja) | 2006-09-05 | 2013-01-30 | 日本電気株式会社 | パケット回復方法、通信システム、情報処理装置およびプログラム |
| JP2008140280A (ja) * | 2006-12-05 | 2008-06-19 | Hitachi Ltd | サーバの運用管理における信頼性強化方法 |
| JP4525762B2 (ja) | 2008-02-04 | 2010-08-18 | 株式会社デンソー | 車両用電子制御装置 |
| WO2010001445A1 (ja) * | 2008-06-30 | 2010-01-07 | 富士通株式会社 | 情報処理装置及び情報処理装置の制御方法 |
| JP5293141B2 (ja) * | 2008-12-16 | 2013-09-18 | 日本電気株式会社 | 冗長システム |
| JP2011022741A (ja) * | 2009-07-15 | 2011-02-03 | Nec Computertechno Ltd | コンピュータシステム、サービスプロセッサ、及びその診断方法 |
| JP5576096B2 (ja) * | 2009-11-16 | 2014-08-20 | 富士通株式会社 | マルチｃｐｕ構成装置及びその監視制御方法 |
| JP5991088B2 (ja) | 2012-08-31 | 2016-09-14 | 富士通株式会社 | 電源制御装置、情報処理装置及び電源制御方法 |
| KR101533081B1 (ko) * | 2014-09-26 | 2015-07-03 | 성균관대학교산학협력단 | 저전력과 신뢰성을 동시에 확보하기 위한 이중화 대응 장치, 이중화 시스템 및 이중화 구성 설정 방법 |
-
1996
- 1996-11-21 JP JP31079596A patent/JP3942216B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JPH10154085A (ja) | 1998-06-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3611894B2 (ja) | 二重化構成をもつシステム制御装置 | |
| US4775976A (en) | Method and apparatus for backing up data transmission system | |
| JP3942216B2 (ja) | 二重化された監視／制御プロセッサによるシステム監視・制御方法およびシステム監視・制御装置 | |
| US7853767B2 (en) | Dual writing device and its control method | |
| US4894828A (en) | Multiple sup swap mechanism | |
| KR20000011835A (ko) | 네트워크의분산애플리케이션에대한고장검출및소정의복제스타일로복구하는방법및장치 | |
| JP5392594B2 (ja) | 仮想計算機冗長化システム、コンピュータシステム、仮想計算機冗長化方法、及びプログラム | |
| KR20000011834A (ko) | 고장-허용오차를계산하는컴퓨터시스템및이를동작시키는방법,고장-관리컴퓨터장치,및고장-허용오차계산장치 | |
| KR20010006847A (ko) | 클러스터 노드 디스트레스 신호 | |
| JP2010140361A (ja) | コンピュータシステム及び異常検出回路 | |
| US20200167249A1 (en) | Information processing system and information processing apparatus | |
| JPH086910A (ja) | クラスタ型計算機システム | |
| JPH09251443A (ja) | 情報処理システムのプロセッサ障害回復処理方法 | |
| JP3001818B2 (ja) | マルチプロセッサ立ち上げ管理装置 | |
| JPH10116261A (ja) | 並列計算機システムのチェックポイントリスタート方法 | |
| JP3343618B2 (ja) | 端末無中断オンラインシステム | |
| KR19990050460A (ko) | 고 가용성 시스템의 장애 복구방법 및 장치 | |
| JP2008250929A (ja) | リンク障害診断方法、ディスクアレイ・システム、及びリンク障害診断プログラム | |
| JP2004013723A (ja) | 共有メモリを使ったクラスタ構成を採用した情報処理システムの障害処理装置と方法 | |
| JPH1196033A (ja) | 情報処理装置 | |
| JP2001175545A (ja) | サーバシステムおよび障害診断方法ならびに記録媒体 | |
| EP1845447B1 (en) | Method, apparatus and software for preventing switch failures in the presence of faults | |
| JP2699291B2 (ja) | 電源異常処理装置 | |
| JP3679412B6 (ja) | 故障から立直りが速い／故障に対する耐性がある計算処理 | |
| JP3679412B2 (ja) | 故障から立直りが速い／故障に対する耐性がある計算処理 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060112 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060328 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060529 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20061010 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061207 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20070109 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070312 |
|
| A911 | Transfer of reconsideration by examiner before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20070316 |
|
| 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: 20070403 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070403 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110413 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110413 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120413 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130413 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140413 Year of fee payment: 7 |
|
| EXPY | Cancellation because of completion of term |