(57)【特許請求の範囲】
【請求項１】
個々の記憶ディスク装置内に保守情報を格納し、該保守情報を分析し、該分析の結果としての交換順序に基づき、前記記憶ディスク装置が実行するプログラム交換方法であり、
複数のプログラム交換パターンに応じたロードプログラムを記憶ディスク装置内に持つことで、選択的に交換順序を決定し、プログラム交換を実行し、
前記記憶ディスク装置は、交換対象のプログラムが格納される部位を局部的に断電する局部断電手段と、前記局部断電手段によって断電された部位に再度通電された場合に前記プログラムの再起動を行う再起動手段と、を有し、
前記保守情報には、プログラム交換世代記録と、プログラム依存関係が含まれ、
前記プログラム交換世代記録には、交換進捗情報と交換障害情報が存在し、
前記交換進捗情報には、プログラム交換時に随時変化する交換状態/進捗状態/構成状態に関する結果とトレースが記録され、
前記交換障害情報には、前記交換進捗情報を監視しながら、障害情報とその障害に対する対処方法のトレースが記録され、
前記プログラム依存関係には、プログラムの各記憶ディスク装置への導入の可否に関する情報、プログラム世代間の交換の可否に関する情報、プログラム相互間の交換の可否に関する情報が記録されており、
前記保守情報の分析により、前記記憶ディスク装置が稼働しているシステム環境に適したプログラムとその交換順序を決定し、
前記プログラム交換の実行の際に前記交換順序性が保たれなかった場合に、前記局部断電手段が、当該プログラムが格納される部位を局部的に断電する断電ステップと、
前記断電ステップによって断電された部位に再度通電するステップと、
前記プログラム交換を再施行するステップと、
前記再施行が終了した後に、前記再起動手段によって前記プログラムの再起動を行うステップとを実行するプログラム交換方法。
【請求項２】
個々の記憶ディスク装置内に保守情報を格納し、該保守情報を分析し、該分析の結果としての交換順序に基づき、前記記憶ディスク装置が実行するプログラム交換方法であり、
複数のプログラム交換パターンに応じたロードプログラムを記憶ディスク装置内に持つことで、選択的に交換順序を決定し、プログラム交換を実行し、
前記記憶ディスク装置は、交換対象のプログラムが格納される部位を局部的に断電する局部断電手段と、前記局部断電手段によって断電された部位に再度通電された場合に前記プログラムの再起動を行う再起動手段と、を有し、
前記保守情報には、プログラム交換世代記録と、プログラム依存関係が含まれ、
前記プログラム交換世代記録には、交換進捗情報と交換障害情報が存在し、
前記交換進捗情報には、プログラム交換時に随時変化する交換状態/進捗状態/構成状態に関する結果とトレースが記録され、
前記交換障害情報には、前記交換進捗情報を監視しながら、障害情報とその障害に対する対処方法のトレースが記録され、
前記プログラム依存関係には、プログラムの各記憶ディスク装置への導入の可否に関する情報、プログラム世代間の交換の可否に関する情報、プログラム相互間の交換の可否に関する情報が記録されており、
前記保守情報の分析により、前記記憶ディスク装置が稼働しているシステム環境に適したプログラムとその交換順序を決定してプログラム交換を実行し、
前記記憶ディスク装置内でプログラム単位に前記記憶ディスク装置の各部位の状態、進捗状況のトレースを記録することにより、局部断電再起動が必要となった場合、前記プログラム交換が失敗した場合、および動作が不安定となった場合のそれぞれの場合に対応したプログラム交換のリカバリーを実行するプログラム交換方法。
【請求項３】
個々の記憶ディスク装置内に保守情報を格納し、該保守情報を分析し、該分析の結果としての交換順序に基づき、前記記憶ディスク装置が実行するプログラム交換方法であり、
複数のプログラム交換パターンに応じたロードプログラムを記憶ディスク装置内に持つことで、選択的に交換順序を決定し、プログラム交換を実行し、
前記記憶ディスク装置は、前記プログラムが格納される部位を局部的に断電する局部断電手段と、前記局部断電手段によって断電された部位に再度通電された場合に前記プログラムの再起動を行う再起動手段と、を有し、
前記交換順序性が保たれなかった場合に、前記局部断電手段が、当該プログラムが格納される部位を局部的に断電する断電ステップと、
前記断電ステップによって断電された部位に再度通電するステップと、
前記プログラム交換を再施行するステップと、
前記再施行が終了した後に、前記再起動手段によって前記プログラムの再起動を行うステップとからなり、
前記記憶ディスク装置内でプログラム単位に前記記憶ディスク装置の各部位の状態、進捗状況のトレースを記録することにより、局部断電再起動が必要となった場合、プログラム交換が失敗した場合、および動作が不安定となった場合のそれぞれの場合に対応したプログラム交換のリカバリーを実行し、
前記記憶ディスク装置の各々の内部には、前記保守情報としてプログラム交換世代記録と、プログラム依存関係が存在しており、前記プログラム交換世代記録の主キーはRAID（製造番号）であり、その主キーのRAIDと同じレベルには、RAIDプログラム（副キー）や交換進捗情報、交換障害情報、交換履歴が存在し、
前記交換進捗情報には、プログラム交換時に随時変化する交換状態/進捗状態/構成状態に関する結果とトレースが記録され、
前記交換障害情報には、前記交換進捗情報を監視しながら、障害情報とその障害に対する対処方法がトレースし記録され、
前記交換履歴には、プログラム交換間（世代間）での情報が記録され、
前記プログラム依存関係には、プログラムの各記憶ディスク装置への導入の可否に関する情報、プログラム世代間の交換の可否に関する情報、プログラム相互間の交換の可否に関する情報が記録され、
前記保守情報の分析により、前記記憶ディスク装置が稼働しているシステム環境に適したプログラムとその交換順序を決定する、
ことを特徴とするプログラム交換方法。
【請求項４】
個々の記憶ディスク装置内に保守情報を格納し、該保守情報を分析し、該分析の結果としての交換順序に基づき、前記記憶ディスク装置がプログラム交換を実行するプログラム交換管理システムであり、
複数のプログラム交換パターンに応じたロードプログラムを記憶ディスク装置内に持つことで、選択的に交換順序を決定し、プログラム交換を実行し、
前記記憶ディスク装置は、前記プログラムが格納される部位を局部的に断電する局部断電手段と、前記局部断電手段によって断電された部位に再度通電された場合に前記プログラムの再起動を行う再起動手段と、を有し、
前記記憶ディスク装置内でプログラム単位に前記記憶ディスク装置の各部位の状態、進捗状況のトレースを記録することにより、局部断電再起動が必要となった場合、プログラム交換が失敗した場合、および動作が不安定となった場合のそれぞれの場合に対応したプログラム交換のリカバリーを実行し、
前記記憶ディスク装置の各々の内部には、前記保守情報としてプログラム交換世代記録と、プログラム依存関係が存在しており、前記プログラム交換世代記録の主キーはRAID（製造番号）であり、その主キーのRAIDと同じレベルには、RAIDプログラム（副キー）や交換進捗情報、交換障害情報、交換履歴が存在し、
前記交換進捗情報には、プログラム交換時に随時変化する交換状態/進捗状態/構成状態に関する結果とトレースが記録され、
前記交換障害情報には、前記交換進捗情報を監視しながら、障害情報とその障害に対する対処方法がトレースし記録され、
前記交換履歴には、プログラム交換間（世代間）での情報が記録され、
前記プログラム依存関係には、プログラムの各記憶ディスク装置への導入の可否に関する情報、プログラム世代間の交換の可否に関する情報、プログラム相互間の交換の可否に関する情報が記録され、
前記保守情報の分析により、前記記憶ディスク装置が稼働しているシステム環境に適したプログラムとその交換順序を決定する、
ことを特徴とするプログラム交換管理システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、プログラム交換技術に関し、特に記憶ディスク装置内にあらゆる保守情報を格納し、この保守情報を分析し、この分析の結果に基づき、プログラム交換を行うようにしたプログラム交換方法に関する。
【０００２】
【従来の技術】
現在、記憶ディスク装置はその機能や構成が複雑になり、個々の記憶ディスク装置レベルで特有の複雑構成を持つようになったので、高度な知識と技術が保守（保守員）に必要となっている。その保守には膨大な情報を得ている保守員でなければ、対応することができなくなっているが、その情報量は人間が得られる範疇を超えようとしているのが現状である。記憶ディスク装置でのプログラム交換はその最たるものとされており、今後の記憶ディスク装置の保守に危惧が持たれている。因みに、ここにいう記憶ディスク装置とは、磁気ディスク装置(RAID=Redundant Array of Inexpensive Disksを含む)やハードディスク装置(HDD)と同義語となっている。また、ここにいうプログラムには、ミドルウェアやファームウェアが含まれる。
【０００３】
【発明が解決しようとする課題】
従来にあっては、顧客からの要求があれば、直ぐに保守員が出向き、一台一台手作業でプログラム交換を実施していた。しかしながら、今後、記憶ディスク装置が多様化/多機能化していくためには、あらゆる面でプログラム交換の自動化が不可欠である。この状況を認識し、図１（本発明に係るプログラム交換システムを示す）を参照しつつ、以下の事例１〜５を課題として紹介する。
【０００４】
事例１
ある不良対策を実現するために、Devicectl1(キャッシュ制御ソフトウェア)とドライブctl1(ドライブ制御ソフトウェア)の同期修正を実施した。ドライブctl1はHDD単独で出荷されることが多々あり、オン中（基幹業務中）でのプログラム交換を実現する上では、ドライブctl1を先に交換する必要があった。この順序を守らないと、レイド（RAID-A）７の電源を一旦、切らなければ、交換したプログラムの対策が有効にならないという課題があった。
【０００５】
理由
事故対策時にDevicectl1とドライブctl1間で新規インタフェースを追加。 DKU(キャッシュ・HDD接続用ハードウェア)マイクロ(マイクロプログラム)が新インタフェースをサポートしているか否かを確認するには、Devicectl1側からInquiry(問合せ)コマンドを発行して確認する。しかしながら、通常、Inquiryコマンドの取込みは、HDD増設やリプレース（RAID内局部を断電（DKAの抜差し））以外では、Devicectl1のマイクロ交換のタイミングしかないため、Devicectl1の交換を実施した後にドライブctl1の交換を実施した場合には、Inquiryコマンドが発行されないため、再度、RAID−Aの電源を一旦、切るか、あるいは再度、Devicectl1の交換が実施されなければ対策が有効にならない。他にも全DKAをダミーリプレースすれば、HDDドライブとの調停を結び直すので有効であるが、これは指示できない。なお、RAID内局部断電が必要とされているのは、RAIDの場合は、多数のユーザが使用しているので、断電することはできない。そこで、局部断電→再起動が必要になる。
【０００６】
因みに、Devicectl1等について補足説明すれば、Devicectl1は各PKctl(パッケージ制御ソフトウェア)1-nにアクセスする機能を持つ。また、ドライブCtl1-nにアクセスする機能を持つ。更に、RAID内のDB(DB：データベース)（RAID-DB）にアクセスする機能を持っている。更にまた、HostctlM(HostctlAアクセスソフトウェア)にアクセスする機能を持っている。これら以外にも、各Port(ポート)に流れる入出力データを監視制御する機能や、PKctl→Portctl(ポート制御ソフトウェア)を経由して監視ctl(ネット内一括監視/管理ソフトウェア)にアクセスする機能を持っている。
【０００７】
以上のように、Devicectl1とは、本システムを全て制御するプログラムを言って過言ではなく、全体を監視制御することで、RAID内の特性の基準値（母数）を持った実績データを収集することが可能となる。例えば基幹入出力時間に対する特性、基幹入出力数に対する特性、Devicectl1のタイムクロックを基準にした特性、エラー数に対した特性、稼動時間に対した特性、稼動機能に対した特性等を採取することができる。
【０００８】
また、ドライブctlは、勿論、定義ファイルを含めたプログラムのことで、通常、HDDに依存したプログラムとなる。HDDの特徴を活かした、付加価値を持ったプログラムである。
【０００９】
事例２
ドライブctl1でSCSIリセットが発行されると、HDDドライブがハングするという問題があり、対策版マイクロを発行した。単独でドライブctl1を更新すれば問題はないが、Devicectl1と一緒に上げる場合には、事例１と同じ様に、ドライブctl1→Devicectl1の順番で実施する必要があった。
【００１０】
理由
Devicectl1交換時にHDDに対してSCSIリセットを入れるため、RAIDが未対策版の場合に、ハングアップするという問題を引き起こすため。対策のためのプログラム交換で手順を誤ると、当該不良を発生させる可能性があった。
【００１１】
事例３
RAIDのXX-12（XX：バージョン、12：レビジョン(revision)）版で、新ドライブサポート情報(互換HDD含む)をDevicectl1側に反映させるため、HDD定義ファイルの交換を実施する手順を追加した。従来の手順は定義ファイルを最後に実施する手順であった。即ち、従来の手順では、HostctlA(ディスクアクセスソフトウェア)→それ以外→定義ファイルであったが、XX-12版未満からXY-12版以降に上げるためには、HostctlA→ドライブctl1以外のプログラム→定義ファイル+HDD定義ファイル→ドライブctl1という手順に変更した。
【００１２】
理由
HDD定義ファイルは各種情報定義ファイルの１つで、HDDに関する各種パラメータが格納されている。HDDには、互換HDDというものがある。この互換HDDとは、新型HDDのことで、大容量、且つ付加価値/付加機能を持っており、従来のHDDとの互換性を保つためにインタフェースを同等とし、加えて新インタフェースが付加されている。古いマイクロ（古いDevicectl1）でも互換HDDは搭載可能であるが、当然、新しいHDDタイプそのものは認識できないため、古いHDDタイプと認識する。ところが、古いタイプのHDDに見えても、実体は新しいタイプのHDDなので、古いマイクロでは、互換HDDのドライブctl1マイクロ交換が実施できない様細工している。XY-12版ではDKRxB/xC(HDDの型名)の互換HDDが認識できるマイクロで、 XY-12未満、且つ互換HDDが搭載されている可能性を考えると、ドライブctl1マイクロ交換前にDevicectl1を認識対応のマイクロに上げ、且つ必要な構成情報をDevicectl1側に渡すという段取りが必要になるので、このようなプログラム交換には順序性が必要となる。一般にHostctlA→Devicectl1であるが、通信のしかたを変更等する場合には、Devicectl1→HostctlAの順序で交換を実施しなければならないケースもある。
【００１３】
事例４
RAIDには、複数RAIDと同期を取って実施する機能（データ移行機能等）が多々ある。例えば、RAID-Aとレイド（RAID−B）３がリンクしデータを移行させる際には、RAID-AとRAID−B内のプログラムも適合したものでなければ機能しない。機能、あるいは用途に合ったプログラムをRAID-AとRAID−Bにインストールしなければならなかった。
【００１４】
事例５
顧客先でのプログラム交換作業で、装置指定（記憶ディスク装置製造番号指定と順番）、プログラムレビジョン指定、時間指定、期間指定等の要求に応えなくてはならず、ON中（基幹常務中）での交換や、実績のある（故障がない）プログラムの交換要求に応えなければならなかった。更に、顧客は常に良い環境であることを希望するが、そのためには、何度も保守員が顧客先に出向く必要があった。
【００１５】
以上の事例１〜５からも判るように、記憶ディスク装置には特殊な事情があり、これら事情を考慮しつつ、プログラム交換を行うことが必要となっている。
【００１６】
本発明の目的は、個々の記憶ディスク装置内に格納されている保守情報を分析し、その分析の結果や、記憶ディスク装置に局部断電・再起動機能を持たせる等することで、順序性が崩れたプログラム交換、または一部のプログラム交換の失敗にも容易に対処可能として、その記憶ディスク装置内でプログラム交換を自動的に行い得るプログラム交換方法を提供することにある。
【００１７】
また、本発明の目的は、保守員が顧客先に出向くことを不要として、即ち、遠隔からの指示により、記憶ディスク装置内でプログラム交換を自動的に行い得るプログラム交換方法を提供することにある。
【００１８】
【課題を解決するための手段】
本発明のプログラム交換方法は、個々の記憶ディスク装置内に保守情報を格納し、該保守情報を分析し、該分析の結果としての交換順序に基づき、プログラム交換を行うようにしたものである。
【００１９】
また、本発明のプログラム交換方法は、複数のプログラム交換パターンに応じたロードプログラムを記憶ディスク装置内に持つことで、選択的に交換順序を決定し、プログラム交換を実行するものである。
【００２０】
さらに、本発明のプログラム交換方法は、前記記憶ディスク装置が、前記プログラムが格納される部位を局部的に断電する局部断電手段と、前記局部断電手段によって断電された部位に再度通電された場合に前記プログラムの再起動を行う再起動手段と、を有し、前記交換順序性が保たれなかった場合に、前記局部断電手段が、当該プログラムが格納される部位を局部的に断電する断電ステップと、前記断電ステップによって断電された部位に再度通電するステップと、前記プログラム交換を再施行するステップと、前記再施行が終了した後に、前記再起動手段によって前記プログラムの再起動を行うステップとからなるものである。
【００２１】
また、本発明のプログラム交換方法は、前記記憶ディスク装置が、前記プログラムが格納される部位を局部的に断電する局部断電手段と、前記局部断電手段によって断電された部位に再度通電された場合に前記プログラムの再起動を行う再起動手段と、を有し、前記記憶ディスク装置内でプログラム単位にトレース管理することにより、局部断電再起動が必要となった場合、プログラム交換が失敗した場合、および動作が不安定となった場合のそれぞれの場合に対応したプログラム交換のリカバリーを実行するものである。
【００２２】
さらに、本発明のプログラム交換方法は、ネット上にホスト、記憶ディスク装置および監視装置が設置されている状態で、前記ホストから前記監視装置にプログラム交換を指定した場合、前記監視装置では、プログラム交換対象の記憶ディスク装置に格納されている保守情報を分析し、該分析の結果としての交換順序に基づき、該記憶ディスク装置にプログラム交換を指示するようにしたものである。
【００２３】
また、本発明のプログラム交換方法は、前記ホストから前記監視装置を介して、複数の前記記憶ディスク装置の各々に、プログラム交換上の個々の設定を行うようにしたものである。
【００２４】
さらに、本発明のプログラム交換方法は、前記ホストからの最適化設定の指示に基づき、前記監視装置では、各々の前記記憶ディスク装置の構成情報、固有実績データ、マイクロ交換進捗情報、障害情報を含む情報を参照し、前記記憶ディスク装置各々の環境を、プログラム交換により、最適環境に変更するようにしたものである。
【００２５】
【発明の実施の形態】
以下、本発明の実施の形態について、図１から図１２により説明するが、その具体的説明に先立って、その概要について簡単ながら説明すれば、以下のとおりである。
【００２６】
即ち、監視装置からネット上の全ての記憶ディスク装置を自動的に監視可能とし、記憶ディスク装置内にあらゆる保守に対応した情報(現象と対応システムと常に蓄積される稼動実績データと相性と癖とプログラムとロードプログラム等)を格納可能とし、この情報を分析することで、最適なプログラムの選出と適合性と最適交換順序等の抽出が可能となり、これまで、人間が作業に介入しなければならなかった局部断電をも自動化し、常に個々の記憶ディスク装置状態を監視解析しながら、個々の記憶ディスク装置環境と使用機能に適合した状態に、ホストからの指示でプログラム交換の実行を可能ならしめたものである。
【００２７】
記憶ディスク装置は、プログラムが格納される部位を局部的に断電する局部断電手段と、前記局部断電手段によって断電された部位に再度通電された場合に前記プログラムの再起動を行う再起動手段と、を有している。
【００２８】
具体的に、事例１，２での課題を解決するには、RAID内のデータベースに、交換規則性と特徴性を記録させ、それを制御するロードプログラムを記憶させておく。また、万が一、同時に実行（交換作業）したプログラムのある一部が失敗し規則性（順序性）が狂った場合でも、自動的に失敗したプログラムをリトライ（再交換）で復活させて、自動的に局部ダミーリプレース（RAID内局部を断電（DKAの抜差し））をすることで、課題を解決すればよい。
【００２９】
また、事例３での課題を解決するには、事例１，２での解決手段に加え、RAID内の全プログラムの管理（レビジョン等）、全構成（HDD）の管理を行うことで、課題を解決できる。
【００３０】
更に、事例４での課題を解決するには、事例１〜３での解決手段に加え、総合管理監視装置(図１に示す監視装置（監視―A）６に相当)を複数RAIDからアクセスできるネット上に配置することで、課題を解決できる。
【００３１】
更にまた、事例５での課題を解決するには、事例１〜４での解決手段に加え、複数のHostが遠隔地からプログラム交換に関する様々な要求を設定実行する機能と、細部的に状態-構成-進捗-障害-稼動率性-障害性-安定性を参照・分析する機能を総合管理監視装置、即ち、監視―Aに持たせることで、課題を解決できる。
【００３２】
さて、本発明について具体的に説明すれば、図１に、本発明に係るプログラム交換システムの一例でのシステム構成を示す。図示のように、ホスト（Host-A）４と監視−AとRAID−AとRAID―BはNET-A(低速ネット-A)で接続されている。ホスト（Host−B）２とレイド（RAID−C）１は別のNET-B(低速ネット-B)で接続されている。NET-AとNET-BはWANで接続されている。RAID−AとRAID−Bと顧客（Client1）５と監視―AはNET(高速ネット)で接続されている。なお、図１は、あくまでも、一例でのシステム構成であるので、ネット規模/各装置規模/各部位は無限の拡張性を持っていることに注意されたい。
【００３３】
Host-Aは、HostctlAとHOSTA-DBを持っている。HostctlAは、記憶ディスク装置とアクセスする時に必要なソフトウェアである。例えば、RAID-AのHostctlMにアクセスしてRAID内の情報を取得、または記憶ディスク装置内に情報に設定することができる。HOSTA-DBはその時に取得した情報や作成した情報を格納し、これら情報は、記憶ディスク装置とのアクセス情報として扱われる。Host-Aの機能はHost−Bも同じように持っている。また、Client1は、NETを経由してRAID―AとRAID―Bに接続されて、入出力データ（この入出力データとは、ファイルデータのような、ディバイス装置が本来の目的で使用するインプット/アウトプットの情報(顧客が基幹業務で扱う情報)を送受信している。
【００３４】
監視―Aは、監視Ctlと監視-DBを持っている。監視ctlは、ネット内を一括監視（状態/構成/マイクロ交換作業）/管理するソフトウェアである。監視ctlは、HostctlAとHostctlMに接続性を持ち、Host-AとRAID-Aとのアクセスを可能としている。Host-Aは監視-AとNET-Aで接続されてアクセスをする。RAID−Aと監視-Aは、NET-AとNETを経由して接続されてアクセスをする。監視―Aは、プログラム交換前に、それぞれのRAIDにプログラムを、NETを介して速やかに格納することができる。監視―Aは、Host-Aからのプログラム交換の詳細な要求を処理し、指定されたRAIDに指定された要求項目で交換要求することができる。交換中のRAIDの状態も、随時、または必要に応じ目的のRAIDから取得することができる。
【００３５】
監視-DBは、HOSTA-DBとRAIDA-DBとの間に位置し、情報の取得/送信と更新を常時可能としている。例えば監視-Aは監視ctlを使って、RAIDA-DBに格納されている構成情報/状態情報/マイクロ交換に必要な情報をNET経由で常時取得/設定できる。その結果、必要なデータは監視-DBに格納される。
【００３６】
RAID-Aは様々な機能を持ったパッケージPK-１〜PK-5／キャッシュメモリ／DKA／物理ドライブ（HDD-A〜HDD-E〜）を装備している。他には、電源やバッテリー、ハブ、センサー等、多くの部位を備えているが、本発明には直接関連がないので、説明を省略する。他のディバイスの詳細部位も同様である。
【００３７】
各パッケージPKは独自のソフトウェアPortctl1/PKctl1/Portctl5/PKctl5で動作している。また、それぞれのパッケージPKは複数のPortを装備し、そのPortからNETに接続されている。Portctl1とPortctl5は、各portを制御するソフトウェアであり、また、PKctl1とPKctl5は、PKの母体となるソフトウェアであり、Devicectl1にアクセスする機能を持つ。
【００３８】
キャッシュはDKAを経由して各PKとディバイス（HDD-A〜HDD-E〜）と物理的に接続されている。キャッシュは主なアクセスが必ず経由されるといって過言でなく、そのキャッシュを制御している母体ソフトウェアがDevicectl1である。このDevicectl1はディバイス（HDD-A〜HDD-E〜）とアクセスする機能を持ち、HostctlAにアクセスするのに必要なHostctlMが存在する。
【００３９】
DKAは、キャッシュとHDDを接続するハードウェアであり、内部はクロス論理となっているので、あるポイントが故障しても、問題なく動作することができるようになっている。
【００４０】
HDD-A〜HDD-Eは、顧客が実際に基幹業務で使用するデータを管理しているもので、そのデータの管理と入出力の制御等を行うドライブctl1〜５を持っている。ドライブctl1〜５はDevicectl1にアクセスする機能を持っている。
【００４１】
次に、図２，図３それぞれに示すプログラム交換世代記録DB（P_Che-DB）について説明すれば、プログラム交換世代記録DBはRAID内に存在するデータベースであり、図１に示すRAID-A内のRAIDA-DBに相当する。このプログラム交換世代記録DBは、本発明に欠かせない情報と、本発明に欠かせない活用の仕組みとなっている。
【００４２】
このプログラム交換世代記録DBは各記憶ディスク装置に存在しており、図２に示すように、主キーはRAID（製造番号）２１となる。主キーのRAID２１と同じレベルには、RAIDプログラム（副キー）２２や交換進捗情報２３、交換障害情報２４、交換履歴２５が存在する。交換進捗情報２３には、プログラム交換時に随時変化する交換状態/進捗状態/構成状態に関する結果とトレースが詳細に記録される。この情報には、例えば障害が発生した瞬間（の時間）での各RAID内部位の状態/進捗状態が、各モジュールレベル／スレッド（thread）レベルで小刻みに記録されているので、著明に解析できる。あらゆる部位‐あらゆる部品・あらゆるプログラム（１プログラム内のスレッド単位）に詳細なスタンプ（時間）とともに記録され、また、顧客がある機能を使用している時のトレースも、詳細なスタンプ（時間）とともに記録される。
【００４３】
交換障害情報２４には、交換進捗情報２３を監視しながら、障害情報とその障害に対する対処方法が詳細にトレースし記録される。この情報には、例えば障害が発生した瞬間の各RAID内部位の状態/進捗状態が各モジュールレベル／スレッドレベルで小刻みに記録されているので、著明に解析できる。どの部位‐どの部品・どのプログラムにどのような障害が発生したか等も記録され、併せて、各対処法でのリカバリー結果等も詳細にスタンプ（時間）とともに記録される。
【００４４】
以上の交換進捗情報２３と交換障害情報２４が活用される場合での一特徴としては、以下のようなものが挙げられる。
１）Ａプログラムは、どのような機能を使用している時に、どのような現象になり易いかが解析できる。
２）Ａプログラムは、どのような機能を使用している時に、どのような安定性-稼動率を実績したかが解析できる。
３）Ａプログラムは、どのような構成の時に、どのような現象になり易いかが解析できる。
４）Ａプログラムは、どのような構成の時に、どのような安定性-稼動率を実績したかが解析できる。
【００４５】
これらの各対処（リカバリー）法の解析が可能で、最適解を分析することが可能となる。
【００４６】
交換履歴２５には、プログラム交換間（世代間）での情報が記録される。例えば、前記の分析/解析の結果を記録しておけば、固有RAIDとしての履歴書として扱うことができる。世代間の特徴や、RAID間の分析等としても扱える。
【００４７】
RAIDプログラム２２は副キーとなり、これには、各世代（番号）情報が格納される。RAIDのプログラムが交換/更新/変更される度に世代番号が採取され、その世代番号内テーブルには、交換時に必要になった/必要となる情報が格納される。ある一部のプログラム交換があった場合にも世代が変わる。この情報は、次のプログラム交換時（次の世代）に必要となる情報である。また、現在の状態を確認/監視するのに必要な情報となる。更に、障害が発生した時の修復の情報としても必要となる。更にまた、世代間の特徴を知る情報として扱える。
【００４８】
世代番号２６はキーとして、世代構成情報２７、交換日２８、世代交換進捗情報２９、世代障害情報３０が存在する。その交換日２８には、プログラム交換された日が記録される。世代交換進捗情報２９には、交換進捗情報の情報が記録される。最新の世代テーブル内の世代交換進捗情報２９には、交換進捗情報２３と同期して同じ情報が記録される。世代が変わる、即ち、プログラム交換されると、それまでの情報が保管される。新しい交換進捗情報２３の情報は、新しい世代テーブルの世代交換進捗情報２９に記録されていく。
【００４９】
世代障害情報３０には、その世代で発生した障害情報/対処方法が詳細に記録される。最新の世代テーブル内の世代障害情報３０には、交換障害情報２４と同期して同じ情報が記録される。世代が変わる、即ち、プログラム交換されると、それまでの情報が保管される。新しい交換障害情報２４の情報は、新しい世代テーブルの世代障害情報３０に記録されていく。
【００５０】
図３に示すように、世代構成情報２７にはキーとして、PK１〜ｎのロケーション情報（PK１のロケーション情報３１）、キャッシュメモリのロケーション情報、物理DISK（HDD１〜ｎ）のロケーション情報、HOST情報、DKAのロケーション情報等のRAID内の構成情報が詳細に記録されている（他の部位については、本発明に直接関係がないので、その説明を割愛）。
【００５１】
PK１〜ｎ（PK-１、PK-2）のロケーション情報には、配置情報が格納されている。その配置情報から、例えばPK-1はSSS（SSS：スロットの名称）スロットに設置されていることが判る。PK１〜ｎ（PK-１、PK-2）のロケーション情報にはキーとして、PKの型名情報３２、Portctl情報３３、PKctl情報３４が格納されている。RAID内の存在するPKロケーション数分のテーブルが存在する。これにより、RAID内のPK実装状態/構成を世代別に把握することができる。
【００５２】
Portctl情報３３は、レビジョン/管理代表レビジョンをキーとして、稼動情報３５、障害情報３６を持っている。（例えばPortctl情報）稼動情報３５には、プログラムの稼動状態/安定性が定期的に記録されることで、次の世代（プログラム交換時）の実績データとして扱える（世代交換進捗情報と世代障害情報内に含まれたPortctl情報だけに特化した部分の詳細な情報を稼動情報に格納）。また、この実績データは、他のRAID（同一構成）で同じプログラムが交換される際での検討資料として扱える。
【００５３】
稼動情報３５としては、RAIDで使用しようしている形態/機能も統括して管理することで、形態/機能に対する稼動情報も採取することができる。例えばRAID−BでPK-1にPortctl-１-Aをインストールしたい場合、RAID-AのPK-1内のPortctl-１-Aの稼動情報を参照して稼動の安定性を確認し、RAID−BにPortctl-１-Aをインストールするか否かの判断資料として扱うことができる。使用しようしている形態/機能も統括して管理しているので、癖のあるプログラム（例えば、形態/機能によって稼動状態が違うプログラム）も判断することができる。監視―Aの監視範囲（接続RAID数）が大きい程、採取できるデータが増えるので、その価値は高まることになる。
【００５４】
（例えばPortctl情報）障害情報３６は、次の世代（プログラム交換時）の実績データとして扱える（世代交換進捗情報と世代障害情報内に含まれたPortctl情報だけに特化した部分の詳細な情報を障害情報に格納）。また、この実績データは、他のRAID（同一構成）で同じプログラムが交換される際での検討資料として扱える。どのような状態で、どのような障害が発生し易いのかを稼動情報と併せて解析することができる。これで、癖のあるプログラム（例えば形態/機能によって、障害の発生率が違うプログラム）も判断することができる。
【００５５】
以下、キャッシュメモリテーブルやDKAテーブル、物理DISK（HDD）テーブル、HOSTテーブル等も、前記PK１〜ｎのロケーションテーブルと同様に構成された上、機能している。因みに、DKAテーブルについて補足説明すれば、図１ではDKAが１つしかないが、実際には複数個存在し、固定されたRAID筐体のロケーションスロットにDKAがインストールされる。このDKAテーブルからは、何れのスロットロケーションに何れのDKAが配置（インストール）されているかが判る。DKAの局部断電とは、この個々のDKAのことで、分割して局部断電することで、ON中でのマイクロ交換が可能となっている。
【００５６】
更に、図４，図５それぞれに示すプログラム依存関係DB（P_Depen-DB）について説明すれば、プログラム依存関係DBもRAID内のRAIDA-DBに格納される。図示のように、１つ１つのプログラム単位に、管理番号４３、プログラム名４１、レビジョン４２、プログラム格納先ポインタ４４、対応ハード（ハード相性）４５、世代相性（相互相性や癖を含む）４６、プログラムカテゴリ、プログラム交換ロードプログラム等が記録されている。また、実際のプログラムもこのDBに記録されている。管理番号４３はそのプログラムを管理している番号であり、１つ々々のプログラムを管理する番号として扱える。
【００５７】
以上のデータ（情報）は製造元から支給されるが、特徴（世代相性-相互相性-癖）については、プログラム交換世代記録DBに記録される実績データを考慮し、修正することが可能である。プログラム交換ロードプログラムには、あらゆるプログラム交換パターンに対応したインストールプログラムを持つ（癖、特徴、実績、相性等を考慮している）。
【００５８】
PK対応型名リストには、プログラムに対応したPKの型名が格納されている。また、PKとプログラムとの相性情報も格納されている。例えばプログラム交換できるPKが複数存在したとしても、様々な情報から優先順位は存在する（最適PKが存在する）。そのハード的/ソフト的/論理構造的解析見地から得られた情報が格納されている。
【００５９】
世代相性４６では、プログラム交換できる可能性がソフト的論理的見地から判断されている。例えばA1,A2,A3,A4のプログラムがあった場合で、現在、A2のプログラムがインストールされていたとする。その時の、あらゆる角度から解析したA1,A2,A3,A4との相性/可能性を解析した情報が格納される。
【００６０】
さて、図６に、本発明のプログラム交換方法の概要を、また、図７に、そのプログラム交換方法が実施される際での処理フロー例を示す。先ず図６から説明すれば、図示のように、RAIDはRAID−DBを持っているが、このRAID-DBには、既述のプログラム交換世代記録DB（P_Che-DB）およびプログラム依存関係DB（P_Depen-DB）の他に、実際のプログラム群とロードプログラムが格納されている。監視−AはそのRAID-DBを参照することで、図８に示すプログラム世代関係表（DB）（P_GenRel-DB）と、図９に示すプログラム相互相性関係表（DB）（P_MutAff-DB）とが生成される。このDBからは、更に、図１０に示すプログラム交換ロード表（DB）（P_ExcLoad-DB）と、図１２に示すプログラム最適環境関係表（DB）（P_F-DB）とを作成できる。
【００６１】
監視−Aは、プログラム交換ロード表（DB）（P_ExcLoad-DB）から、実環境に最も適したプログラム交換手順とその交換の実行を可能とするロードプログラムを参照することができる。プログラム交換方法には色々なパターンがあるが、最適な交換方法は限られ、それぞれに交換成功の確率が高い順に優先順位が存在する。監視−Aはそのプログラム交換ロード表を参照することができ、また、格納されたアドレス（ロードプログラム格納先）も知ることができるので、監視−Aはロードプログラムを起動することができる。図１０に示すように、交換優先順位は簡単に順番として付けられているが、実際には、環境/構成/ON中状態により前後する場合があり得る。
【００６２】
監視−Aが取得/生成できるDBはHost-Aからみることができる。実際にロードプログラムを起動指示するのはHost-Aである。このHost-Aが取得した情報はHOST-DBに格納することができる。
【００６３】
次に、例えば図１を参照しつつ、図７によりプログラム交換方法が実施される際での処理フローについて説明すれば、先ず実際のプログラム交換に先立っては、監視―Aによりプログラム依存関係DBのデータと各プログラムがRAID-A内のRAIDA-DBに格納される（ステップS１，S2）。この作業はプログラムが変わる（レビジョンUP）時に行われ、併せて、プログラム依存関係DBデータも更新されることで、常に最新番が格納される仕組みとなっている。また、監視―AとRAID−Aはプログラム交換作業に拘らず、常に密接に係わっており、監視―Aからは障害/状態/構成/進捗等の情報が随時、アクセスにより取得されており（ステップS3）、Host-Aはまた、任意に監視―Aにアクセスすることで、それら障害/状態/構成/進捗等の情報を取得できる。
【００６４】
Host-Aは任意のタイミングで監視―Aに対し、指定するRAIDのプログラム交換指定をすることができるが、その際での指定の仕方は様々で、複数RAIDに同時に指定することもできるし、また、一部のプログラムのみ、指定のレビジョン、複数プログラム同時起動指定、時間指定等、様々な指定が可能となっている（ステップS4）。例えばRAID−A（製造番号AAAA）、……………の指定で監視―Aに命令したとすれば、監視―Aではそれを受け取り、対象のRAID−Aが指定された設定で実行できるか否か、交換組合せの確認をする（ステップS5）。その交換組合せ確認では、先ずステップ３で読み込んでおいたプログラム交換世代記録DBとプログラム依存関係DBが分析されることで、図８に示すプログラム世代関係表（DB）が作成された上、各プログラム単位に世代相性と対応ハードの面で交換が可能か否かが解析される。プログラム世代関係表（DB）では、表内データは新しいプログラムをRAIDーDBにインストールする時に更新される。追加された個々のプログラムについての特徴が格納される。表には３個のプログラムしかないが、実際には、インストールされたプログラムの数だけ存在する。
【００６５】
具体的に、例えば表内のPortctl1で説明すると、表中は「C-A」のプログラムだけであるが、実際は様々なレビジョン（「A-A」「A‐B」..「C-A」.etc..）が格納されている。この個々のプログラムには他に属性が付加されている。対応ハードは「C-A」で動作可能（インストール可能）なPKの型名を全て格納する。世代相性では、プログラムを交換する際の世代相性（交換成功可能性）を記述する。この世代相性では、現在、バージョンがCで、レビジョンがAのプログラム、即ち、「C-A」のプログラムがインストールされているとすると、この状態で「F-A」をインストールした場合での相性を知ることができ、「C-A」から「F-A」へのレビジョン変更は可能であることが判る。表中は１プログラム（「F-A」）についての相性しか示されていないが、実際には、保管された全てのプログラムについての相性をも知ることができる（「C-A」をベースに「A-A」「A‐B」..「C-A」.etc..への交換相性）。尤も、表中の世代相性では、単に「OK」としてしか示されていないが、実際には、詳細な分析結果が格納されている（交換の成功率、ハード間の交換時相性、環境/構成/使用状態（ON中）での交換の可能性等）。プログラム格納先ポインタには、実際にプログラムが格納された位置を示すポインタが格納されている。
【００６６】
次には、図９に示すプログラム相互相性関係表（DB）が作成される。これにより、インストールされるプログラム間で相互相性が分析されるが、これも、実際には、プログラムの癖、稼動中機能との相性、稼働率-安定性-故障率-実績データから分析される。その表中の認識ID「O#」は図１０に示す「O＃」とリンクしている。本システムには、役割を持った複数のプログラムが存在するが、その個々のプログラムの種類別に認識IDが付けられている。
【００６７】
ここで、例えば「O#1  Portctl-1」によりプログラム相互相性関係表（DB）の説明をすれば、プログラムの種類別に認識IDが付けられるが、個々のプログラムには複数のレビジョンが存在するので、あるプログラムには複数の認識IDが存在することになる。この表の主キーはレビジョンであり、相互相性リストでは、レビジョン「C-A」をベースに各種プログラムについての相性を知ることができる。
【００６８】
次に、それら分析結果から顧客の環境（装置）に一番適した交換方法が導出される。いくつか有る候補に、これまでの分析結果を考慮し、優先順位を決めるが、問題がなければ、優先順位の高いものからRAID―Aに対し交換命令を実行する一方、問題があれば（交換が不可能ならば）、そこで終了し、Host-Aに知らせる。
【００６９】
RAID-Aは、監視―Aから交換命令を受け取ると、格納されたロードプログラムとインストールするプログラムをキャッシュに読み込み、読み込みが完了すると、インストールが開始される（ステップS6）。そのインストールの進捗状況は随時、監視―AとHost-Aから確認可能とされる（ステップS7）。
【００７０】
もしも、全交換完了前に、万が一、障害が発生したとしても、交換対象のプログラムに対してリトライインストールをすることも可能であり（ステップS8〜S10）、その場合、既述の事例１，２のような順序性が必要な場合は、自動的に判断し、保守員が介在することなく、図１１に示すように、局部断電・再起動処理をすることで回避することができる（ステップS11）。また、万が一、回避策が上手く行かず、何度もリトライが発生した場合は、監視―A経由でHost-Aに問い合わせ、プログラム交換を中止することができる（ステップS12）。しかし、プログラム交換を中止することを回避する選択もできる。その場合、図１２に示すように、最適環境関係表（DB）（P_F-DB）が作成される。例えば、今回、ドライブctl1のあるレビジョンをインストール中に、リトライ交換を実施しても、また、局部断電処理をしても、プログラム交換が成功しなかった場合には、最適環境関係表（DB）（P_F-DB）が作成・参照される。この最適環境関係表には、各プログラムの各Rev（レビジョン）単位に詳細な最適環境に係る情報が格納されているので、ここからRAID環境-用途に合ったプログラムをHost-Aが選択することができる。この図１２に示す情報は、監視―Aがネット内の各RAIDから採取できるので、一番適した実績データ、相性データ、障害データを知ることが可能となる。
【００７１】
因みに、図１２に示す最適環境関係表（DB）（P_F-DB）について補足説明すれば、図示のように、追加属性として、稼動機能、稼動実績および障害情報が格納されているが、これら稼動機能、稼動実績、障害情報は各稼動機能をキーとして情報が格納されている。この表を使用することで、環境/構成/ON中状態にした最適なシステム環境を構築することが可能となる。稼動機能（例えばドライブctl1−「A-A」についての動作可能な（お勧め）機能を格納）からは、対象プログラムがインストールされている状態で、どのように機能していたかが判るようになっている。また、稼動実績からは、対象プログラムがインストールされている状態で、どの程度安定して動作していたかが判るようになっている。例えばドライブctl1−「A-A」で「FF」の機能が1020時間、問題無く動作したような情報が判るようになっている。稼動機能単位に稼動実績を分析することも可能である。更に、障害情報からは、障害の内容と件数、機能別の件数、障害のレベル等のプログラムが持つ癖が分析可能となっている。例えばドライブctl1−「A-A」で「FF」の機能が1020時間で「ZZ」のエラーが3回発生したような情報が判るようになっており、エラー内容も詳細にどこの部位にどんなレベルでどの時点でどんな風にエラーが発生したか等の情報が判るようになっている他、処理能力も格納可能となっている。更にまた、相性リストは、図８に示す世代相性の概念と同じもので、これからは、全体の相性が分析される。相互相対リストも、図９に示す相互相対リストの概念と同じもので、これからは、全体の相性が分析される。
【００７２】
したがって、以上のようにして、各種情報が判ると、例えば、ある顧客サイトでドライブctlの性能に不満を持っており、「FF」機能が動作している状態で、ドライブctl―「C-C」がインストールされていることで、最大性能を発揮できないことが、図１２から知ることができる。この場合の最適プログラムは、「A-A」であることを知ることができる。また、顧客サイトでは、「FF」機能だけでなく、例えば「GG」機能や「JJ」機能も動作させることがあると予想される。このような場合には、図１２を参照し、最適プログラム交換を行うことによって、場合にあった最適環境を構築することが可能となる。
【００７３】
図７に戻り、説明を続行すれば、Host-Aはこれらの情報を基に、再度、回復策の実行（最適プログラムのインストール）を指定するが（ステップS13，S14）、候補の最適プログラムの中から監視―Aが自動的に判断して、回復策の実行を指定することもできる。万が一、これによるプログラム交換が失敗した場合は、監視―Aを介しHost-Aに報告されるが、そのプログラム交換に失敗することなく、プログラム交換が全て完了すれば、それぞれのDB更新後、監視―Aを経由してHost-Aに完了の報告を行い、その後、随時、状態監視を行う（ステップS15，S8，S16）。
【００７４】
ところで、突然の不具合、即ち、局部断電再起動が必要となった場合、プログラム交換が失敗した場合、動作が不安定となった場合には、記憶ディスク装置内でプログラム単位に詳細にトレース管理することで、それぞれに対応したプログラム交換のリカバリーが可能となっている。突然の不具合とは、プログラム交換時の異常で交換ができなくなってしまったり、基幹入出力障害、あるいは顧客の不満を回避するためのプログラム交換のことで、適切な回避策を持ったロードプログラムを使うことで、遠隔地からのプログラム交換を可能とする。ハード系（局部断電→再起動）のエラーだけでなく、交換異常の原因は数限りがない。ここでいう不具合とは、DBで回復可能なソフト系の回復対策である。世代間相性や相互間相性で発生するエラーや、並列処理で起こるエラー、潜在問題によるエラーのような、予想できないようなエラーが発生した場合でも、途中でプログラム交換を中止することなく自動的に続行するか、ブレイク確認画面を保守員に通知することで、続行するか否かを判断できるようにする。
【００７５】
最後に、最適化論理について説明すれば、この最適化論理は、プログラム交換の時だけでなく、自動監視/実行化することができる。Host-AからRAID-Aのみに最適化設定の指示を行うとする。自動化のスケジューリングの設定も行う。監視―Aはその設定指示を受け取ると、各RAIDの各プログラム単位に、図１２に示すようなプログラム最適環境関係表（DB）を作成し、RAID―Aに係る情報をマージ(合成)し、RAID-Aの環境/稼動状態/機能実力を監視し、最適なプログラムを選択しフレキシブルにインストールし、常に最大限の実力を発揮させるように環境を自動的に調整する。
【００７６】
以上、本発明について説明した。なお、特許請求の範囲に記載された発明以外の発明としては、以下のような発明も考えられる。
（１）：個々の記憶ディスク装置内に稼動実績データ／安定性／故障性／相性等の分析データを格納していくことで、最適なプログラム交換を可能とするプログラム交換管理システム。
（２）：前記システムにおいて、あらゆる状態に応じたロードプログラムを記憶ディスク装置内に持つことで、複雑な条件から順序性が必要なプログラム交換に適した最適なプログラム交換を可能とするプログラム交換管理システム。
（３）：前記システムにおいて、記憶ディスク装置に局部断電機能を持つことで、万が一、順序性が崩れたプログラム交換や一部のプログラムが失敗したときも人間の介入無く、自動的に回避できるプログラム交換管理システム。
（４）：前記システムにおいて、記憶ディスク装置内でプログラム単位に詳細に管理することで突然の不具合にも迅速に対応できるプログラム交換管理システム。
（５）：前記システムにおいて、ネット上に複数HOSTと複数記憶ディスク装置と監視装置を設置することで、接続されたHOSTから監視装置に詳細なプログラム交換（装置/プログラム名/時間等）を指定することができるプログラム交換管理システム。
（６）：前記システムにおいて、ネット上に接続されたHOSTから監視装置を経由して複数の記憶ディスク装置に個々設定を同時に複雑な設定（最適化自動化指定や遅延指定）ができるプログラム交換管理システム。
（７）：前記システムにおいて、ネット上に接続された監視装置は、各記憶ディスク装置の構成情報、固有の実績データ、マイクロ交換進捗情報、障害情報等を参照し、対象の記憶ディスク装置環境の実力を最大限に発揮できる最適環境に自動的に変更することできるプログラム交換管理システム。
【００７７】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲内で種々変更可能であることはいうまでもない。
【００７８】
【発明の効果】
個々の記憶ディスク装置内に格納されている保守情報を分析し、その分析の結果や、記憶ディスク装置に局部断電・再起動機能を持たせる等することで、順序性が崩れたプログラム交換、または一部のプログラム交換の失敗にも容易に対処可能として、その記憶ディスク装置内でプログラム交換を自動的に行い得る。
【００７９】
また、保守員が顧客先に出向くこと不要として、即ち、遠隔からの指示により、記憶ディスク装置内でプログラム交換を自動的に行い得る。
【図面の簡単な説明】
【図１】本発明に係るプログラム交換システムの一例でのシステム構成を示す図である。
【図２】本発明に係るプログラム交換世代記録DB（その１）の一例を示す図である。
【図３】同じく、プログラム交換世代記録DB（その２）の一例を示す図である。
【図４】本発明に係るプログラム依存関係DB（その１）の一例を示す図である。
【図５】同じく、プログラム依存関係DB（その２）の一例を示す図である。
【図６】本発明のプログラム交換方法の概要を説明するための図である。
【図７】そのプログラム交換方法が実施される際での処理フロー例を示す図である。
【図８】本発明に係る一例でのプログラム世代関係表（DB）を示す図である。
【図９】本発明に係る一例でのプログラム相互相性関係表（DB）を示す図である。
【図１０】本発明に係る一例でのプログラム交換ロード表（DB）を示す図である。
【図１１】本発明に係る一例でのドライブCTL障害フローを示す図である。
【図１２】本発明に係る一例でのプログラム最適環境関係表（DB）を示す図である。
【符号の説明】
１，３，７…レイド、２，４…ホスト、５…顧客、６…監視装置。
【図１】
0004275903.tif 000002
【図２】
0004275903.tif 000003
【図３】
0004275903.tif 000004
【図４】
0004275903.tif 000005
【図５】
0004275903.tif 000006
【図６】
0004275903.tif 000007
【図７】
0004275903.tif 000008
【図８】
0004275903.tif 000009
【図９】
0004275903.tif 000010
【図１０】
0004275903.tif 000011
【図１１】
0004275903.tif 000012
【図１２】
0004275903.tif 000013