(57)【特許請求の範囲】
【請求項１】
外部装置とデータを送受するインタフェース部と、
前記インタフェース部の動作態様を設定するための設定データを前記インタフェース部へ送信することにより、前記インタフェース部の動作を制御する第１制御部と、
前記第１制御部が所定の異常状態である場合に前記第１制御部に代わって前記インタフェース部の動作を制御する第２制御部と、
を備え、
前記第１制御部と前記第２制御部のそれぞれは、前記設定データに対する前記インタフェース部の応答データを保持するための不揮発性メモリを有し、
前記インタフェース部は、前記第１制御部から設定データを受け付けた場合に、その設定データに対する応答データを前記第１制御部と前記第２制御部の両方へ送信し、
前記第１制御部と前記第２制御部のそれぞれは、前記インタフェース部から受け付けた応答データを自身が有する不揮発性メモリへ並行して格納し、
前記第１制御部と前記第２制御部のそれぞれが有する不揮発性メモリのうち少なくとも一方の不揮発性メモリは、前記インタフェース部の現在の状態を示す情報を格納すべき運用系の記憶領域と、前記運用系の記憶領域をバックアップするための待機系の記憶領域と、予備系の記憶領域と、記憶領域の管理情報とを含むものであり、
前記第１制御部と前記第２制御部の少なくとも一方は、
前記インタフェース部から応答データを受け付けた場合に、その応答データを前記予備系の記憶領域へ格納し、
ユーザから更新命令を受け付けた場合に、前記予備系の記憶領域の格納データを前記運用系または待機系の記憶領域へコピーするとともに、前記予備系の記憶領域を新たな運用系または待機系の記憶領域として前記管理情報を更新し、前記予備系の記憶領域の格納データをコピーする対象外とした前記運用系または待機系の記憶領域を新たな予備系の記憶領域として前記管理情報を更新することを特徴とする通信装置。
【請求項２】
前記第２制御部は、前記インタフェース部から受け付けた応答データの少なくとも一部を照合用データとして前記第１制御部へ送信し、
前記第１制御部は、前記インタフェース部から受け付けた応答データと、前記第２制御部から受け付けた照合用データを照合することにより、前記第２制御部と前記インタフェース部との間の通信の正常性を確認することを特徴とする請求項１に記載の通信装置。
【請求項３】
通信装置が実行する方法であって、
運用系の制御部が、外部装置とデータを送受するインタフェース部の動作態様を設定するための設定データを前記インタフェース部へ送信するステップと、
前記インタフェース部が、前記運用系の制御部から設定データを受け付け、その設定データに対する応答データを前記運用系の制御部と待機系の制御部の両方へ送信するステップと、
前記運用系の制御部と前記待機系の制御部のそれぞれが、前記インタフェース部から応答データを受け付け、その応答データを自身が有する不揮発性メモリへ並行して格納するステップと、
を備え、
前記運用系の制御部と前記待機系の制御部のそれぞれが有する不揮発性メモリのうち少なくとも一方の不揮発性メモリは、前記インタフェース部の現在の状態を示す情報を格納すべき運用系の記憶領域と、前記運用系の記憶領域をバックアップするための待機系の記憶領域と、予備系の記憶領域と、記憶領域の管理情報とを含むものであり、
前記運用系の制御部と前記待機系の制御部の少なくとも一方が、
前記インタフェース部から応答データを受け付けた場合に、その応答データを前記予備系の記憶領域へ格納し、
ユーザから更新命令を受け付けた場合に、前記予備系の記憶領域の格納データを前記運用系または待機系の記憶領域へコピーするとともに、前記予備系の記憶領域を新たな運用系または待機系の記憶領域として前記管理情報を更新し、前記予備系の記憶領域の格納データをコピーする対象外とした前記運用系または待機系の記憶領域を新たな予備系の記憶領域として前記管理情報を更新することを特徴とする通信装置の設定方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明はデータ処理技術に関し、特に通信装置および通信装置の設定方法に関する。
【背景技術】
【０００２】
レイヤ２スイッチ等の通信装置は、外部のユーザ装置やユーザ企業網等から送信された主信号に対する各種処理を実行する主信号系装置と、主信号系装置の動作を監視し制御するための監視制御系装置とを備えることがある。また、通信装置の耐障害性を向上させるために、監視制御系装置が冗長構成となることもある。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０００−２５３０２８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
監視制御系装置は主信号系装置の設定情報のバックアップデータを保持することがあり、監視制御系装置が冗長構成をとる場合、運用系の監視制御系装置と待機系の監視制御系装置との間でバックアップデータの同期を維持する必要がある。これまでは、通信装置の起動処理中や初期の運用設置、運用設定の変更後において、運用系におけるバックアップデータの更新後に、待機系におけるバックアップデータを更新していたため、通信装置の起動に長時間を要することがあった。
【０００５】
本発明は、こうした課題に鑑みてなされたものであり、その主たる目的は、主信号系装置の設定処理に係る冗長化された監視制御系装置間の同期を効率的に維持するための技術を提供することである。
【課題を解決するための手段】
【０００６】
上記課題を解決するために、本発明のある態様の通信装置は、外部装置とデータを送受するインタフェース部と、インタフェース部の動作態様を設定するための設定データをインタフェース部へ送信することにより、インタフェース部の動作を制御する第１制御部と、第１制御部が所定の異常状態である場合に第１制御部に代わってインタフェース部の動作を制御する第２制御部と、を備える。第１制御部と第２制御部のそれぞれは、設定データに対するインタフェース部の応答データを保持するための不揮発性メモリを有する。インタフェース部は、第１制御部から設定データを受け付けた場合に、その設定データに対する応答データを第１制御部と第２制御部の両方へ送信し、第１制御部と第２制御部のそれぞれは、インタフェース部から受け付けた応答データを自身が有する不揮発性メモリへ並行して格納する。
【０００７】
本発明の別の態様は、通信装置の設定方法である。この方法は、通信装置が実行する方法であって、運用系の制御部が、外部装置とデータを送受するインタフェース部の動作態様を設定するための設定データをインタフェース部へ送信するステップと、インタフェース部が、運用系の制御部から設定データを受け付け、その設定データに対する応答データを運用系の制御部と待機系の制御部の両方へ送信するステップと、運用系の制御部と待機系の制御部のそれぞれが、インタフェース部から応答データを受け付け、その応答データを自身が有する不揮発性メモリへ並行して格納するステップと、を備える。
【０００８】
なお、以上の構成要素の任意の組合せ、本発明の表現を、装置、方法、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【０００９】
本発明の通信装置によれば、主信号系装置の設定処理に係る冗長化された監視制御系装置間の同期を効率的に維持することができる。
【図面の簡単な説明】
【００１０】
【図１】実施の形態の通信装置のハードウェア構成を示す図である。
【図２】ＤＢの構成を模式的に示す図である。
【図３】従来の通信装置の動作を示すフローチャートである。
【図４】従来の通信装置の動作を示す模式図である。
【図５】実施の形態の運用系制御盤の機能構成を示すブロック図である。
【図６】制御フレームの構成を示す図である。
【図７】実施の形態のＩＦ盤の機能構成を示すブロック図である。
【図８】実施の形態の通信装置の動作を示すフローチャートである。
【図９】実施の形態の通信装置の動作を示す模式図である。
【図１０】通信装置の動作状態のバリエーションを示す図である。
【発明を実施するための形態】
【００１１】
図１は、実施の形態の通信装置のハードウェア構成を示す。通信装置１００は、ユーザ装置やユーザ企業網等から送信された主信号を中継する装置であり、典型的にはレイヤ２スイッチ等のイーサネット伝送装置（「イーサネット」は登録商標）であるが、レイヤ３スイッチ等、他の種類の伝送装置であってもよい。通信装置１００は、運用系制御盤１０と、待機系制御盤２０と、インタフェース（ＩＦ）盤３０で総称されるＩＦ盤３０ａ、ＩＦ盤３０ｂ・・・を備える。
【００１２】
ＩＦ盤３０は主信号の中継処理を実行する。例えば装置外部の伝送路（不図示）から通信ポート（不図示）を介して主信号としてのイーサネットフレームを受信する。また、イーサネットフレームに設定されたＭＡＣアドレスに応じたスイッチ処理を実行し、通信ポートを介してイーサネットフレームを伝送路へ送出する。ＩＦ盤３０は、通信装置１００における主信号系の配下カードであり、インタフェースカードとも呼ばれる。
【００１３】
ＩＦ盤３０は、ＣＰＵ３２とメモリ３４とＰＨＹ３６を備える。メモリ３４は、ＩＦ盤３０の動作態様、言い換えれば、主信号処理の態様を規定する情報（以下「動作設定情報」、「設定データ」とも呼ぶ。）を保持する。動作設定情報には、回線設定用のパスデータや通信ポートの開閉情報、ＶＬＡＮの情報（帯域幅の設定値等）、主信号のフィルタリング条件、学習テーブルの情報（ＭＡＣアドレステーブルの内容）等が含まれる。後述するように、動作設定情報は運用系制御盤１０により設定される。ＰＨＹ３６は、装置内ＬＡＮとのインタフェースであり、例えばＬＡＮ用通信ポートである。ＣＰＵ３２は、ＰＨＹ３６で受け付けられた動作設定情報をメモリ３４に格納し、またメモリ３４に保持された動作設定情報にしたがって主信号の中継処理を実行する。
【００１４】
運用系制御盤１０と待機系制御盤２０は、冗長化された監視制御系装置である。運用系制御盤１０は、アクティブ系・現用系として動作するＣＰＵカードであり、ＩＦ盤３０の動作態様を制御する。待機系制御盤２０は、スタンバイ系・予備系として動作するＣＰＵカードであり、運用系制御盤１０が予め定められた異常状態になったことを検出した場合に、運用系制御盤１０に代わってＩＦ盤３０の動作態様を制御する。この異常状態には、ＣＰＵ・メモリ・ＤＢ等のハードウェア故障や、ソフトウェア処理の異常、通信異常等が含まれる。
【００１５】
運用系制御盤１０は、ＣＰＵ１２とメインメモリ１４とＤＢ１６とＬ２ＳＷ１８とＰＨＹ１９を備える。メインメモリ１４は、ＩＦ盤３０の動作態様を示す情報、言い換えれば、ＩＦ盤３０の動作設定情報を保持する。メインメモリ１４は揮発性メモリであり、例えばＤＲＡＭであってもよい。ＤＢ１６は、ＩＦ盤３０の動作態様を示す情報、言い換えれば、ＩＦ盤３０の動作設定情報のバックアップデータを保持する。ＤＢ１６は不揮発性メモリであり、例えばＥＥＰＲＯＭやフラッシュメモリであってもよい。
【００１６】
ＣＰＵ１２は、メインメモリ１４に保持されたデータを参照して運用系制御盤１０の動作を制御する。また保守者端末２００から、予め定められたコマンドを受け付けて、そのコマンドに応じた処理を実行する。設定コマンドを受け付けた場合や通信装置１００の起動時には、ＣＰＵ１２は、ＤＢ１６に保持されたＩＦ盤３０の動作設定情報を取得し、その情報にもとづいてＩＦ盤３０の動作態様を設定し、例えば上記したようにＩＦ盤３０の回線設定や通信ポート設定、ＶＬＡＮ設定等を実行する。Ｌ２ＳＷ１８は、待機系制御盤２０やＩＦ盤３０とイーサネット通信を行うためのレイヤ２スイッチである。ＰＨＹ１９は、装置内ＬＡＮとのインタフェースであり、例えばＬＡＮ用通信ポートである。
【００１７】
待機系制御盤２０は、運用系制御盤１０と同様の構成であり、ＣＰＵ２２とメインメモリ２４とＤＢ２６とＬ２ＳＷ２８とＰＨＹ２９を備える。図１の運用系制御盤１０、待機系制御盤２０、ＩＦ盤３０は装置内ＬＡＮを介して互いにデータ（後述の制御フレームを含む）を送受する。例えば、運用系制御盤１０と待機系制御盤２０は、ＣＰＵ間通信用のＬＡＮである装置内ＬＡＮ４０を介して通信する。同様に、運用系制御盤１０とＩＦ盤３０ａは装置内ＬＡＮ４２を介して通信し、運用系制御盤１０とＩＦ盤３０ｂは装置内ＬＡＮ４４を介して通信し、待機系制御盤２０とＩＦ盤３０ａは装置内ＬＡＮ４６を介して通信し、待機系制御盤２０とＩＦ盤３０ｂは装置内ＬＡＮ４８を介して通信する。
【００１８】
図２は、ＤＢの構成を模式的に示す。図２の（ａ）は、従来の運用系制御盤におけるＤＢの構成を示している。従来の運用系制御盤のＤＢは、図において０面と呼ぶ記憶領域（以下「ＤＢ０面」とも呼ぶ。）と、ＤＢ０面のバックアップ領域であり図において１面と呼ぶ記憶領域（以下「ＤＢ１面」とも呼ぶ。）を備えるものであった。ＤＢ０面は運用系の記憶領域、ＤＢ１面は待機系の記憶領域ともいえ、運用系制御盤１０のＣＰＵ１２はＤＢ０面からＩＦ盤３０の動作設定情報を読み出す。
【００１９】
これに対して図２の（ｂ）は、本実施の形態のＤＢ１６およびＤＢ２６の構成を示している。ＤＢ１６およびＤＢ２６は、従来のＤＢに対してさらなる冗長構成が付加された３面構成となっている。具体的には、ＤＢ０面とＤＢ１面に加えて、図においてＲ面と呼ぶ予備的・付加的な記憶領域（以下「ＤＢＲ面」とも呼ぶ。）を備える。詳細は後述するが、ＤＢＲ面としての記憶領域はＤＢ内をローテーションする。そのためＤＢ１６およびＤＢ２６は、ＤＢメモリ内の記憶領域の範囲と、面種別（すなわちＤＢ０面か、１面か、Ｒ面かの識別情報）とを対応づけたＤＢ管理情報をさらに備える。運用系制御盤１０のＣＰＵ１２は、ＤＢ管理情報を参照してＤＢ０面を特定し、ＤＢ０面からＩＦ盤３０の動作設定情報を読み出す。
【００２０】
図３は、従来の通信装置の動作を示すフローチャートである。同図は、運用系制御盤１０がＩＦ盤３０の動作態様を設定するときの動作を示している。
まず設定単位数分（本実施の形態では制御フレーム数分であり、すなわち設定データ数分）のループ処理を開始する（Ｓ１０）。運用系制御盤１０のＣＰＵ１２は、保守者端末２００から受け付けられたＩＦ盤３０に対する設定データ、またはメインメモリ１４から取得した設定データ、またはＤＢ１６から取得した設定データをＩＦ盤３０へ送信する（Ｓ１２）。ＩＦ盤３０のＣＰＵ３２は、運用系制御盤１０から受け付けた設定データにしたがってＩＦ盤３０の動作態様を設定し、例えばメモリ３４に保持された設定データを更新する（Ｓ１４）。ＩＦ盤３０のＣＰＵ３２は、ＩＦ盤３０の設定処理を完了すると、設定データに対する応答データを運用系制御盤１０へ送信する（Ｓ１６）。運用系制御盤１０のＣＰＵ１２は、その応答データをメインメモリ１４へ蓄積する（Ｓ１８）。以上のＳ１２〜Ｓ１８の処理を設定データ数分繰り返す（Ｓ２０）。
【００２１】
通信装置１００は、運用系制御盤１０および待機系制御盤２０のＤＢの更新を指示するコマンド、言い換えれば、運用系制御盤１０のメインメモリに保持された応答データを不揮発性メモリに永続的に記憶させるよう指示するコマンド（以下「ＤＢセーブコマンド」とも呼ぶ。）を保守者端末２００から受け付ける。運用系制御盤１０のＣＰＵ１２は、ＤＢセーブコマンドを受け付けると、メインメモリ１４に保持された応答データをＤＢ０面へ格納し、その後、ＤＢ０面のデータをＤＢ１面へコピーする（Ｓ２２）。そして、ＤＢ１６の更新が終了すると、メインメモリ１４に保持された応答データを待機系制御盤２０へ転送し、その応答データを待機系のメインメモリ２４に保持させる（Ｓ２４）。待機系制御盤２０のＣＰＵ２２は、運用系制御盤１０から転送された応答データをＤＢ０面へ格納し、その後、ＤＢ０面のデータをＤＢ１面へコピーする（Ｓ２６）。
【００２２】
図４は、従来の通信装置の動作を示す模式図である。同図において、運用系制御盤１０がＩＦ盤３０へ設定データの送信を開始してから、待機系制御盤２０のＤＢ２６の更新完了までの期間が、ＩＦ盤３０の設定処理に要する時間（以下「設定処理時間」とも呼ぶ。）となる。この設定処理時間が長くなるほど、通信装置１００全体の起動に要する時間も長くなる。また、ＤＢセーブコマンドを受け付けてから、待機系制御盤２０のＤＢ２６の更新完了までの時間が、保守者による操作（コマンド）が許可されない時間（以下「操作不可時間」とも呼ぶ。）となる。
【００２３】
ここで、本発明者が認識した従来の通信装置における課題を説明する。
課題１：通常、待機系である待機系制御盤２０とＩＦ盤３０間の通信の正常性は監視されていないため、運用系制御盤１０から待機系制御盤２０への切替後、言い換えれば、待機系制御盤２０を運用系へ遷移させた後に、待機系制御盤２０とＩＦ盤３０間の通信異常が顕在化することがある。この場合、待機系による復旧が困難となり、通信装置１００の復旧に長時間を要してしまう。
【００２４】
課題２：待機系である待機系制御盤２０のＤＢ２６は、運用系である運用系制御盤１０のＤＢ１６と同期させる必要があるが、これまでは、装置起動処理中や初期の運用設置、運用設定の変更後は、ＤＢ１６の更新完了後にＤＢ１６とＤＢ２６を同期させる構成であった。そのため、図４の設定処理時間で示したように、待機系のＤＢ２６の更新が完了するまでに長時間を要し、待機系制御盤２０の起動処理に長時間を要してしまう。結果として、通信装置１００が冗長構成完了状態となるまでに長時間を要してしまう。また、運用系である運用系制御盤１０のＣＰＵ１２に、ＩＦ盤３０の設定処理や待機系制御盤２０との同期処理等が集中し、ＣＰＵ１２が高負荷となってしまう。
【００２５】
課題３：ＤＢ１６およびＤＢ２６は、ＩＦ盤３０の設定データを永続的に保持する必要があるため、データ更新速度等のアクセス速度が低速な不揮発性メモリである。例えば、ＤＢ１６およびＤＢ２６へのアクセスに要する時間は、揮発性メモリへのアクセスに要する時間の１０倍程度になることもある。また、通信装置１００の設定情報をＤＢへ保存する間は、運用系制御盤１０と待機系制御盤２０との整合性を維持するため、運用系制御盤１０はユーザ操作によるオペレーションを保守者端末２００から受け付けない。これまでの通信装置では、図４で示した操作不可時間が長時間になってしまうことがある。
【００２６】
課題４：ＤＢ１６およびＤＢ２６は不揮発性メモリであるため、偶発的なデバイス故障やメモリセルでのチャージロス（charge loss）により、保持しているデータのビット化けが発生することがある。また、製造不良によるロット（lot）故障等により、ＤＢ故障となることがある。これまでのＤＢメモリにおける２面構成では、故障復旧の確率、さらに言えば、運用系で動作継続できる確率が低いことが懸念される。
【００２７】
以上の本発明者が認識した課題を解決するための、実施の形態の通信装置１００の構成を詳細に説明する。図５は、実施の形態の運用系制御盤１０の機能構成を示すブロック図である。運用系制御盤１０は、コマンド取得部５０と、設定データ取得部５２と、設定データ送信部５４と、応答データ取得部５６と、応答データ転送部５８と、照合部６０と、アラート通知部６２と、ＤＢ更新部６４を備える。
【００２８】
本明細書のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのＣＰＵやメモリをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。例えば、図５の各機能ブロックはプログラムモジュールとして実装されてメインメモリ１４に保持されてもよく、ＣＰＵ１２はそれらのプログラムモジュールを読み出して実行することにより各機能ブロックの機能を実現してもよい。
【００２９】
コマンド取得部５０は、保守者端末２００において保守担当者が入力したコマンド（例えばＩＦ盤３０の設定コマンドやＤＢセーブコマンド）を保守者端末２００から受け付ける。コマンド取得部５０は、ＤＢセーブコマンドを受け付けた場合、そのコマンドを待機系制御盤２０へ転送する。
【００３０】
設定データ取得部５２は、保守者端末２００から設定コマンドが受け付けられた場合、その設定コマンドが含むＩＦ盤３０の設定データを取得する。また通信装置１００の起動時に、ＤＢ１６に保持されたＩＦ盤３０の設定データを取得する。設定データ送信部５４は、設定データ取得部５２により取得された設定データを含むイーサネットフレームである制御フレームを作成する。そして、作成した制御フレームを、装置内ＬＡＮを介してＩＦ盤３０へ送信する。
【００３１】
図６は制御フレームの構成を示す。制御フレームは、運用系同期フラグ７０と、待機系同期フラグ７２と、通し番号７４と、オプション７６と、設定データ７８を含む。運用系同期フラグ７０は、ＩＦ盤３０の応答データを運用系制御盤１０のＤＢ１６へ反映させるか（「１」）か否か（「０」）を指定するデータである。待機系同期フラグ７２は、ＩＦ盤３０の応答データを待機系制御盤２０のＤＢ２６へ反映させるか（「１」）か否か（「０」）を指定するデータである。例えば、運用系同期フラグ７０＝１、待機系同期フラグ７２＝０は、ＩＦ盤３０の応答データを運用系のＤＢ１６へ反映させる一方、待機系のＤＢ２６へは反映させないことを意味する。本実施の形態では、運用系同期フラグ７０＝１、待機系同期フラグ７２＝１に設定されることとする。
【００３２】
通し番号７４は、制御フレームごとにユニークな値となる制御フレームの識別情報であり、実施の形態では、制御フレームごとにインクリメントされた連番が設定される。例えば、設定データ送信部５４は、最後に作成した制御フレームの通し番号をメインメモリ１４へ格納しておき、次に作成する制御フレームの通し番号として、メインメモリ１４に格納しておいた通し番号をインクリメントした値を設定してもよい。オプション７６は、実施の形態では言及しないが、各種処理のための予約フィールドである。設定データ７８は、設定データを格納するフィールドであり、制御盤→ＩＦ盤への設定データであることを示すデータを含む。
【００３３】
図５に戻り、応答データ取得部５６は、ＩＦ盤３０から送信された制御フレームであり、設定データに対する応答データを含む制御フレーム（以下、「応答フレーム」とも呼ぶ。）をＩＦ盤３０から受け付ける。この応答フレームも図６の制御フレームと同様の構成であり、その設定データ７８には、運用系制御盤１０から送信した設定データが応答データとして格納されるとともに、ＩＦ盤→制御盤への応答データであることを示すデータも格納される。応答データ取得部５６は、ＩＦ盤３０から受け付けた応答フレームから応答データを取得して、その応答データをメインメモリ１４へ格納する。
【００３４】
応答データ転送部５８は、待機系制御盤２０としての機能、すなわち運用系制御盤１０が待機系に切り替えられた後に発揮される機能であるため後述する。
【００３５】
照合部６０は、ＩＦ盤３０から自装置宛に送信された応答フレームと、ＩＦ盤３０から待機系制御盤２０宛に送信されて待機系制御盤２０から転送された応答フレームとを照合して、両方の応答フレームが整合するものであるか否かを判定する。ＩＦ盤３０から自装置宛に送信された応答フレームは、運用系制御盤１０とＩＦ盤３０間のＬＡＮを介して伝送されたフレームである一方、待機系制御盤２０宛に送信されて待機系制御盤２０から転送された応答フレームは、待機系制御盤２０とＩＦ盤３０間のＬＡＮを介して伝送されたフレームである。すなわち照合部６０は、これらのフレームが整合するか否かを判定することにより、待機系制御盤２０とＩＦ盤３０間のＬＡＮ通信の正常性を確認する。
【００３６】
実施の形態では、照合部６０は、ＩＦ盤３０から直接受け付けた応答フレームに設定された通し番号と、待機系制御盤２０から通知された通し番号とが一致するか否かを判定する。アラート通知部６２は、照合部６０による照合の結果、ＩＦ盤３０から直接受け付けた応答フレームに設定された通し番号と、待機系制御盤２０から通知された通し番号とが不一致と判定された場合、すなわち、ＩＦ盤３０から自装置宛に送信された応答フレームと、ＩＦ盤３０から待機系制御盤２０宛に送信されて待機系制御盤２０から転送された応答フレームとが不整合と判定された場合に、その旨を示すアラート情報を保守者端末２００へ通知する。このアラート情報には、待機系制御盤２０とＩＦ盤３０間の通信異常の可能性を保守者へ提示する情報が含まれてもよい。
【００３７】
ＤＢ更新部６４は、応答フレームの運用系同期フラグ７０に「１」が設定されていた場合にＤＢ１６の更新処理を実行し、言い換えれば、ＩＦ盤３０からの応答データをＤＢ１６へ反映させる。本実施の形態では同フラグに「１」が設定されることとする。
【００３８】
具体的には、ＤＢ更新部６４は、応答データ取得部５６により応答フレームが受け付けられたときに、その応答フレームに設定された応答データをＤＢＲ面へ格納する。ＤＢ更新部６４は、コマンド取得部５０によりＤＢセーブコマンドが受け付けられたときに、ＤＢＲ面が保持するデータをＤＢ０面へコピーする。それと並行して、それまでのＤＢＲ面→新たなＤＢ０面、それまでのＤＢ０面→新たなＤＢ１面、それまでのＤＢ１面→新たなＤＢＲ面とするようＤＢ管理情報を更新する。言い換えれば、ＤＢ管理情報における、記憶領域と面種別との対応関係を変更する。これにより、ＤＢ１６においてＤＢ０面・１面・Ｒ面がローテーションすることになり、言い換えれば、応答データの書込み位置もローテーションすることになる。
【００３９】
通信装置１００の待機系制御盤２０の機能構成も図５で示したとおりである。ただし、待機系制御盤２０が待機系として動作する間は、コマンド取得部５０、設定データ取得部５２、設定データ送信部５４、照合部６０、アラート通知部６２の機能の発揮は抑制される。そして待機系制御盤２０が運用系へ切り替えられた場合に、上記の運用系制御盤１０の機能を発揮する。以下では、待機系制御盤２０が待機系として動作する場合の機能を説明する。
【００４０】
応答データ取得部５６は、ＩＦ盤３０から送信された応答フレームを受け付け、その応答フレームに設定された応答データをメインメモリ２４へ格納する。応答データ転送部５８は、応答フレームに設定された通し番号を抽出して運用系制御盤１０へ通知する。ＤＢ更新部６４は、応答フレームの待機系同期フラグ７２に「１」が設定されていた場合、運用系制御盤１０におけるＤＢ１６の更新処理と同様の、ＤＢ２６の更新処理を実行する。本実施の形態では同フラグに「１」が設定されることとする。
【００４１】
図７は、実施の形態のＩＦ盤３０の機能構成を示すブロック図である。ＩＦ盤３０は、設定データ受信部８０と、設定処理部８２と、応答データ送信部８４と、主信号処理部８６を備える。図７の各機能ブロックはプログラムモジュールとして実装されてメモリ３４に保持されてもよく、ＣＰＵ３２はそれらのプログラムモジュールを読み出して実行することにより各機能ブロックの機能を実現してもよい。
【００４２】
設定データ受信部８０は、運用系制御盤１０から送信された制御フレームを受け付ける。設定処理部８２は、制御フレームに設定された設定データをメモリ３４へ格納することにより、設定データをＩＦ盤３０に反映する。応答データ送信部８４は、設定処理部８２による設定データの反映処理後、応答フレームを作成して運用系制御盤１０と待機系制御盤２０の両方へ送信する。主信号処理部８６は、メモリ３４に格納された設定データを参照し、その設定データで規定された態様にて、主信号に対する各種中継処理、例えば受信処理・スイッチ処理・送出処理・フィルタリング処理・帯域割当処理等を実行する。
【００４３】
以上の構成による通信装置１００の動作を以下説明する。
図８は、実施の形態の通信装置１００の動作を示すフローチャートである。図８も図３と同様に、運用系制御盤１０がＩＦ盤３０の動作態様を設定するときの動作を示すものである。図８には不図示であるが、ＩＦ盤３０の主信号処理部８６は、運用系制御盤１０により設定された動作態様で、主信号の中継処理を実行する。
【００４４】
ＩＦ盤３０の設定タイミングになったことが検出されると（Ｓ３０のＹ）、設定データ数分のループ処理を開始する（Ｓ３２）。例えば、コマンド取得部５０がＩＦ盤３０に対する設定コマンドを受け付けた場合に、設定データ取得部５２がＩＦ盤３０の設定タイミングに至ったと判定して、その設定コマンドから設定データを取得してもよく、その設定コマンドに応じてＤＢ０面から設定データを取得してもよい。また、通信装置１００の起動時に、設定データ取得部５２がＩＦ盤３０の設定タイミングに至ったと判定して、ＤＢ０面から設定データを取得してもよい。
【００４５】
運用系制御盤１０の設定データ送信部５４は、設定データ取得部５２が取得した設定データを含む制御フレームをＩＦ盤３０へ送信する（Ｓ３４）。ＩＦ盤３０の設定データ受信部８０は、運用系制御盤１０が送信した制御フレームを受信し、その制御フレームから設定データを取得する。ＩＦ盤３０の設定処理部８２は、設定データにしたがってＩＦ盤３０の動作態様を変更する（Ｓ３６）。ＩＦ盤３０の応答データ送信部８４は、制御フレームに対する応答フレームを運用系制御盤１０と待機系制御盤２０の両方へ送信する（Ｓ３８）。運用系制御盤１０の応答データ取得部５６は、応答フレームを受け付けて、応答フレームに含まれる応答データをメインメモリ１４へ格納する。並行して、待機系制御盤２０の応答データ取得部５６は、応答フレームを受け付けて、応答フレームに含まれる応答データをメインメモリ２４へ格納する。
【００４６】
ここで待機系制御盤２０の応答データ転送部５８は、応答フレームに含まれる通し番号を運用系制御盤１０へ転送する。運用系制御盤１０の照合部６０は、ＩＦ盤３０から直接受け付けた応答フレームに含まれる通し番号と、待機系制御盤２０から転送された通し番号とを照合し、両者が一致するか否かを確認する（Ｓ４０）。通し番号が不一致の場合（Ｓ４２のＮ）、運用系制御盤１０のアラート通知部６２は、その旨を示すアラート情報を保守者端末２００へ通知する（Ｓ４４）。通し番号が一致すれば（Ｓ４２のＹ）、Ｓ４４をスキップする。運用系制御盤１０のＤＢ更新部６４は、ＤＢセーブコマンドを待つことなく、ＩＦ盤３０から受け付けられた応答データをＤＢＲ面へ格納する（Ｓ４６）。これに並行して、待機系制御盤２０のＤＢ更新部６４も同じく動作する。以上のＳ３４〜Ｓ４６の処理を設定データ数分繰り返す（Ｓ４８）。ＩＦ盤３０の設定タイミングになったことが未検出であれば（Ｓ３０のＮ）、Ｓ３２〜Ｓ４８をスキップする。
【００４７】
ＤＢセーブコマンドを保守者端末２００から受け付けた場合（Ｓ５０のＹ）、運用系制御盤１０のコマンド取得部５０は、そのＤＢセーブコマンドを待機系制御盤２０へ転送する。運用系制御盤１０のＤＢ更新部６４はＤＢ１６の更新処理を実行し、これに並行して、待機系制御盤２０のＤＢ更新部６４はＤＢ２６の更新処理を実行する。具体的には、ＤＢＲ面に格納されたデータをＤＢ０面へコピーする（Ｓ５２）。またこれに並行して、ＤＢの面種別を変更するようにＤＢ管理情報を更新する（Ｓ５４）。ＤＢセーブコマンドを受け付けなければ（Ｓ５０のＮ）、Ｓ５２およびＳ５４をスキップする。
【００４８】
図９は、実施の形態の通信装置の動作を示す模式図である。図９の（ａ）は、ＩＦ盤３０が運用系制御盤１０と待機系制御盤２０の両方へ応答フレームを返す点が図３と異なる。これにより、ＤＢセーブコマンドを受け付けた場合に、運用系制御盤１０でのＤＢ１６の更新処理と、待機系制御盤２０でのＤＢ２６の更新処理とを並行して実行でき、設定処理時間および操作不可時間を短縮することができる。
【００４９】
図９の（ｂ）は、実施の形態の通信装置１００の動作に対応し、ＩＦ盤３０が運用系制御盤１０と待機系制御盤２０の両方へ応答フレームを返す点と、ＤＢ１６およびＤＢ２６が３面化された点が図３と異なる。これにより、アクセス速度が低速な不揮発性メモリに対する応答データの書込み（すなわちＤＢＲ面の更新）をＤＢセーブコマンドを受け付ける以前に行うことができる。また、ＤＢセーブコマンドを受け付けたときには、ＤＢ０面へのコピーと、それまでのＤＢＲ面を新ＤＢ０面とし、それまでのＤＢ０面を新ＤＢ１面とするよう管理情報を書き換えるだけである。したがって、ＤＢセーブコマンドを受け付けてからＤＢ更新処理が完了するまでの時間をさらに短縮し、設定処理時間および操作不可時間をさらに短縮することができる。
【００５０】
実施の形態の通信装置１００によると、ＩＦ盤３０を設定する単位、すなわち制御フレームを送信する単位で、ＩＦ盤３０からの応答データが待機系制御盤２０へも送信され、運用系のＤＢ１６の更新処理と待機系のＤＢ２６の更新処理を並行して実行できる。これにより、設定処理時間を短縮することができ、例えば通信装置１００の起動時間を短縮することができる。またこれまでは、運用系制御盤１０のＣＰＵ１２が、ＩＦ盤３０に対する設定処理や待機系制御盤２０への同期処理を一括して実行していたが、ＩＦ盤３０のＣＰＵ３２および待機系制御盤２０のＣＰＵ２２がその一部の処理を担うことで、運用系制御盤１０のＣＰＵ１２の負荷を分散し、通信装置１００の起動時間を短縮することができる。
【００５１】
また通信装置１００によると、通常動作中において、待機系監視制御伝送路の正常性を監視することができる。具体的には、待機系制御盤２０〜ＩＦ盤３０の通信用ＬＡＮである装置内ＬＡＮ４６や装置内ＬＡＮ４８の通信の正常性を確認することができる。これにより、待機系制御盤２０が運用系へ切り替わるまでＩＦ盤３０との通信異常が発見されず、待機系制御盤２０が運用系へ切り替わるときにその問題が顕在化して、通信装置１００の復旧時間が長くなってしまうことを防止できる。
【００５２】
また通信装置１００によると、ＤＢを３面構成としたことにより、ＤＢセーブコマンドを受け付けてからＤＢ更新処理が完了するまでの時間を短縮し、設定処理時間および操作不可時間を短縮できる。また３面化することにより、警報の監視の向上、故障復旧での耐力も向上し偶発故障時の復旧可能な確率を向上することができる。また、通信装置の保守運用観点では運用系で動作継続できることが望ましいが、ＤＢを３面構成としたことにより、運用系での動作継続できる確率を向上することができる。
【００５３】
図１０は、通信装置１００の動作状態のバリエーションを示す。図１０の（ａ）はＤＢ２面構成、図１０の（ｂ）はＤＢ３面構成を示している。ここで、ＤＢ１６の０面・１面・Ｒ面、ＤＢ２６の０面・１面・Ｒ面それぞれの故障確率は等しいこととし、ＤＢ１６の０面・１面・Ｒ面のいずれかが正常であれば運用系で動作継続できることとしている。ＤＢのＲ面のみが正常の場合は、ＩＦ盤３０の最新設定情報が反映されていない可能性はあるが、運用系制御盤１０のメインメモリ１４に最新設定情報が蓄積されているため、メインメモリ１４からＤＢのＲ面へ最新設定情報をコピー等することにより、ＤＢのＲ面へ最新設定情報を格納して運用継続を図ることができる。図１０で示すように、運用系で動作継続できる確率はＤＢ２面構成に比べ向上する。これにより、柔軟な保守運用を可能にする。
【００５４】
さらに運用を考慮すると、ＤＢ管理情報の更新により、運用系・待機系ともに、ＤＢメモリの各記憶領域をＲ面→０面→１面とローテーションさせることで、実際に使用している不揮発性メモリの物理領域を巡回させることができる。これにより、通常状態でのＤＢ物理領域全面の故障監視（例えばチャージロスやビット故障、ロット不良等の監視）が可能になる。また、従来はＤＢセーブコマンド実行時にのみＤＢへアクセスしていたが、本実施の形態の方式では、装置設定や変更を実施するたびにＤＢＲ面へアクセスし、アクセス頻度が上がることで故障検出の早期化が可能になる。
【００５５】
なお実施の形態では、運用系のＤＢ１６と待機系のＤＢ２６の両方が３面構成であることとしたが、このうち一方が３面構成で、他方が２面構成の通信装置１００であってもよいことはもちろんである。この場合も、ＤＢが３面構成の制御盤では上記効果を奏する。
【００５６】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００５７】
請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連携によって実現されることも当業者には理解されるところである。
【符号の説明】
【００５８】
１０  運用系制御盤、  １６  ＤＢ、  ２０  待機系制御盤、  ２６  ＤＢ、  ３０  ＩＦ盤、  １００  通信装置。
【図１】
0005711169.tif 000002
【図２】
0005711169.tif 000003
【図３】
0005711169.tif 000004
【図４】
0005711169.tif 000005
【図５】
0005711169.tif 000006
【図６】
0005711169.tif 000007
【図７】
0005711169.tif 000008
【図８】
0005711169.tif 000009
【図９】
0005711169.tif 000010
【図１０】
0005711169.tif 000011