(57)【特許請求の範囲】
【請求項１】
第１の制御部と該第１の制御部とは独立した第２の制御部を備える装置と、
前記装置のメンテナンスデータを管理するメンテナンスデータ管理サーバと、
を備え、
前記第１の制御部は前記装置を制御し、エラー発生時には、前記メンテナンスデータに基づくエラー処理論理により処理結果を得て、メンテナンスの手順を生成し、
前記第２の制御部は、前記メンテナンスデータ管理サーバから前記メンテナンスデータをダウンロードして前記第１の制御部に転送し、前記第１の制御部から転送されるメンテナンス結果を前記メンテナンスデータ管理サーバに送信し、かつ正常時にはメンテナンスデータに含まれるログ解析論理に従って装置の障害の過去ログを解析し、装置の部品の障害履歴を抽出して部品の障害発生を予測するとともに、エラー発生時には前記第２の制御部はログ解析を行い前記第１の制御部による処理結果の妥当性をチェックする装置メンテナンスシステム。
【請求項２】
前記第１の制御部はメモリを備え、前記転送されたメンテナンスデータは、第１の制御部が活性の状態で前記第１の制御部の前記メモリのメンテナンスデータ領域に展開される請求項１に記載の装置メンテナンスシステム。
【請求項３】
前記メンテナンスデータ管理サーバから既知障害データを受信する既知障害データベースを有するリモートメンテナンス・サーバを備え、前記装置で障害が発生すると、前記リモートメンテナンス・サーバに通知され、リモートメンテナンス・サーバで既知障害データとの比較が行われ、既知の障害か未知の障害かが判定される請求項１または請求項２に記載の装置メンテナンスシステム。
【請求項４】
第１の制御部と該第１の制御部とは独立した第２の制御部を備える装置と、
前記装置のメンテナンスデータを管理するメンテナンスデータ管理サーバと、
を備える装置メンテナンスシステムの装置メンテナンス方法であって、
前記第２の制御部は、前記メンテナンスデータ管理サーバから前記メンテナンスデータをダウンロードして前記第１の制御部に転送し、
前記第１の制御部は前記装置を制御し、エラー発生時には、前記メンテナンスデータに基づくエラー処理論理により処理結果を得て、メンテナンス手順を生成し、
前記第１の制御部は、メンテナンス終了後、メンテナンス結果を前記第２の制御部に転送し、
前記第２の制御部は、転送された前記メンテナンス結果を前記メンテナンスデータ管理サーバに送信し、
前記第２の制御部は、正常時には、装置の障害の過去ログを解析し、装置の部品の障害履歴を抽出し、部品の障害発生を予測するとともに、エラー発生時には前記第２の制御部はログ解析を行い前記第１の制御部による処理結果の妥当性をチェックする装置メンテナンス方法。
【請求項５】
情報処理装置であって、
前記情報処理装置を制御する第１の制御部と、
前記第１の制御部とは独立した第２の制御部を備え、
前記第１の制御部は、エラー発生時には、前記メンテナンスデータに基づくエラー処理論理により処理結果を得て、メンテナンスの手順を生成し、
前記第２の制御部は、メンテナンスデータ管理サーバから前記メンテナンスデータをダウンロードして前記第１の制御部に転送し、前記第１の制御部から転送されるメンテナンス結果を前記メンテナンスデータ管理サーバに送信し、かつ正常時にはメンテナンスデータに含まれるログ解析論理に従って装置の障害の過去ログを解析し、装置の部品の障害履歴を抽出して部品の障害発生を予測するとともに、エラー発生時には前記第２の制御部はログ解析を行い前記第１の制御部による処理結果の妥当性をチェックする情報処理装置。
【請求項６】
前記第１の制御部はメモリを備え、前記転送されたメンテナンスデータは、第１の制御部が活性の状態で前記第１の制御部の前記メモリのメンテナンスデータ領域に展開される請求項５に記載の情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、装置で発生する障害をメンテナンスする装置メンテナンスのためのシステム、方法および情報処理装置に関し、特に装置のメンテナンスデータを集中管理する装置メンテナンスのためのシステム、方法および情報処理装置に関する。
【背景技術】
【０００２】
一般に、製品あるいは装置の企画開発時、製造時、顧客先での稼動時のいずれにおいても、さまざまな不具合、故障、エラーなどの障害が発生し、その都度解決されている。障害には、例えば製品の開発部門での設計不良、製造工場での初期不良あるいはロット不良、顧客フィールドでの顧客環境特有の不良あるいは経年不良などがある。障害はそれぞれ、発生した場所でそれぞれ解決されるが、障害の解決策、解決のためのノウハウは共有されることはなかった。したがって、発生した障害が、工場では既知の障害であっても、顧客先で発生した場合、顧客先の担当者は、適切な保守手順を見つけることができず、復旧に時間を要してしまう場合があった。また、問合せを受けたサポート担当者が誤った解決策を指示してしまうこともあった。
【０００３】
さらにファームウェアで制御される装置では、ネットワークを介してリモートメンテナンスセンタに接続して、装置を監視することが行われているが、装置に最新のメンテナンスデータが集約されていないので、装置で発生した障害の対策を装置の担当者で解決できないということもあった。
【０００４】
なお、従来においては、複写機のデータを自動的に収集してセンターで管理するシステムであって、センターで作業指針を自動的に出力するシステムが提案されている（特許文献１参照）。また、ネットワークに接続された電気製品について故障した回路を特定する故障診断情報を各戸から送信し、顧客情報や製品情報を管理する保守修理サービスセンターで電気製品の故障診断を行うシステムに用いられる、保守サービス要員が携帯する電気製品故障分析用の情報取得ツールであって、電気製品の故障の分析に有用な詳細情報を取得するものが提案されている（特許文献２参照）。さらに、製品の開発・設計、製品の生産・出荷および市場における製品の流通に至る一連のライフプロセスにおいて発生する品質不良を一元管理することが提案されている（特許文献３参照）。さらに、複数の部門間を結合する情報通信ネットワークにおける知識情報ネットワークにおける知識情報管理方法であって、対照データベースを構築し、該対照データベースを参照して登録されている知識や情報を利用可能にする窓口を、情報通信ネットワーク上に設けることが提案されている（特許文献４参照）。
【０００５】
【特許文献１】特開平５−６１２８３号公報
【特許文献２】特開２００２−８３１１８公報
【特許文献３】特開２００２−１０９１３８号公報
【特許文献４】特開２００４−２１９４２
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上述の問題に鑑み、最新のメンテナンスデータを集約して保持し、装置に最新のメンテナンスデータを反映させることができる装置メンテナンスシステム、装置メンテナンス方法、情報処理装置が提供される。
【課題を解決するための手段】
【０００７】
本システムによれば、第１の制御部と該第１の制御部とは独立した第２の制御部を備える装置と、前記装置のメンテナンスデータを管理するメンテナンスデータ管理サーバと、を備え、前記第１の制御部は前記装置を制御し、エラー発生時には、前記メンテナンスデータに基づくエラー処理論理により処理結果を得て、メンテナンスの手順を生成し、前記第２の制御部は、前記メンテナンスデータ管理サーバから前記メンテナンスデータをダウンロードして前記第１の制御部に転送し、前記第１の制御部から転送されるメンテナンス結果を前記メンテナンスデータ管理サーバに送信し、かつ正常時にはメンテナンスデータに含まれるログ解析論理に従って装置の障害の過去ログを解析し、装置の部品の障害履歴を抽出して部品の障害発生を予測するとともに、エラー発生時には前記第２の制御部はログ解析を行い前記第１の制御部による処理結果の妥当性をチェックする装置メンテナンスシステムが提供される。
【０００８】
本方法によれば、第１の制御部と該第１の制御部とは独立した第２の制御部を備える装置と、前記装置のメンテナンスデータを管理するメンテナンスデータ管理サーバと、
を備える装置メンテナンスシステムの装置メンテナンス方法であって、前記第２の制御部は、前記メンテナンスデータ管理サーバから前記メンテナンスデータをダウンロードして前記第１の制御部に転送し、前記第１の制御部は前記装置を制御し、エラー発生時には、前記メンテナンスデータに基づくエラー処理論理により処理結果を得て、メンテナンス手順を生成し、前記第１の制御部は、メンテナンス終了後、メンテナンス結果を前記第２の制御部に転送し、前記第２の制御部は、転送された前記メンテナンス結果を前記メンテナンスデータ管理サーバに送信し、前記第２の制御部は、正常時には、装置の障害の過去ログを解析し、装置の部品の障害履歴を抽出し、部品の障害発生を予測するとともに、エラー発生時には前記第２の制御部はログ解析を行い前記第１の制御部による処理結果の妥当性をチェックする装置メンテナンス方法が提供される。
本装置によれば、情報処理装置であって、前記情報処理装置を制御する第１の制御部と、前記第１の制御部とは独立した第２の制御部を備え、前記第１の制御部は、エラー発生時には、前記メンテナンスデータに基づくエラー処理論理により処理結果を得て、メンテナンスの手順を生成し、前記第２の制御部は、メンテナンスデータ管理サーバから前記メンテナンスデータをダウンロードして前記第１の制御部に転送し、前記第１の制御部から転送されるメンテナンス結果を前記メンテナンスデータ管理サーバに送信し、かつ正常時にはメンテナンスデータに含まれるログ解析論理に従って装置の障害の過去ログを解析し、装置の部品の障害履歴を抽出して部品の障害発生を予測するとともに、エラー発生時には前記第２の制御部はログ解析を行い前記第1の制御部による処理結果の妥当性をチェックする情報処理装置が提供される。
【発明の効果】
【０００９】
本システム、方法あるいは情報処理装置では、最新のメンテナンスデータを集約して保持することができ、装置に最新のメンテナンスデータを反映させることができる。
【発明を実施するための最良の形態】
【００１０】
以下、図面を参照して、実施の形態を説明する。
【００１１】
図１は、本実施形態の装置メンテナンスシステム１０の全体構成を示す図である。
【００１２】
装置メンテナンスシステム１０において、監視および保守の対象はＲＡＩＤ（Redundant Arrays of independent or inexpensive drives）装置１である。ＲＡＩＤ装置１は、複数のハードディスクを並べたディスクアレイ装置であって、装置構成に冗長性をもたせて、信頼性を高めて動作させるものである。ＲＡＩＤ装置１は、ＲＡＩＤ装置本体を制御するＲＡＩＤコントローラ１１と、ＲＡＩＤ装置１とは独立して動作するサービスプロセッサ（ＳＶＰ）１２を有している。サービスプロセッサ１２は、インターネットのような通信ネットワークを介して装置メンテナンスシステム１０に接続している。
【００１３】
装置メンテナンスシステム１０には、通常は複数のＲＡＩＤ装置が接続されていて、それぞれが装置メンテナンスシステム１０の監視および保守の対象となっている。図１では、複数のＲＡＩＤ装置のうちの１台をＲＡＩＤ装置１として示している。メンテナンス対象であるＲＡＩＤ装置は単なる一例であり、ＣＰＵあるいはＭＰＵなどで制御される装置であれば、サーバあるいは家電製品などどのような装置にも適用できる。
【００１４】
サーバで構成されるメンテナンスデータ管理センタ２は、装置の研究開発段階、製造段階、稼動段階などで発生した障害について、障害とその対策とを一括して集中的に管理するセンタであり、被疑個所、保守手順、各種レポートなどを格納し、オンタイムで登録あるいは更新されるメンテナンスデータベース２１を備えている。メンテナンスデータ管理センタ２は、インターネットを介して、さらに装置１の開発に関わる開発評価部門３、装置１を製造する製造工場４、装置のサポートに関わる事業部／サポート部門５と接続されている。
【００１５】
開発評価部門３および製造工場４は、それぞれ自部門で発生した障害データを蓄積する障害データベース３１、４１を有している。開発評価部門３あるいは製造工場４で障害が発生すると、障害データベース３１または４１に障害データが格納されるともに、事業部／サポート部門５に通知され集約される。
【００１６】
事業部／サポート部門５は、メンテナンスデータ管理センタ２のメンテナンスデータベース２１に、集約された障害データを登録する。障害が解決されると、事業部／サポート部門５は、メンテナンスデータベース２１に障害原因、部品交換手順などの解決手順さらには関連情報、参考資料などを登録する。
【００１７】
サーバで構成されるリモートメンテナンスセンタ７は、インターネットを介して、ＲＡＩＤ装置１に接続され、ＲＡＩＤ装置１を常時監視している。リモートメンテナンスセンタ７は、メンテナンスデータ管理センタ２とインターネットを介して接続され、メンテナンスデータ管理センタ２から既知障害データを受信して更新する既知障害データベース７１を備えている。また、リモートメンテナンスセンタ７は、メンテナンスデータ管理センタ２に対して装置メンテナンスシステム１０に接続されているすべてのＲＡＩＤ装置の機種、設置場所等の接続情報を送信することができる。
【００１８】
図１では、リモートメンテナンスセンタ７はメンテナンスデータ管理センタ２と独立して構成されているが、リモートメンテナンスセンタ７とメンテナンスデータ管理センタ２と一体に構成することもできる。
【００１９】
図２は、メンテナンスデータ管理センタの登録監視機能を説明する図である。
【００２０】
メンテナンスデータ管理センタ２は、発生した障害や保守作業の結果の登録漏れをなくすための登録監視機能２２を備えることもできる。前述のように、発生した障害は、発生した個所でデータベース化されるとともに、メンテナンスデータ管理センタ２に通知される。しかしながら、この登録監視機能２２は、各所の障害データベースに蓄積されている障害履歴の変更を監視して、変更があるとメンテナンスデータベース２１に追加してゆくものである。さらに、発生した障害に対して、障害原因、保守手順などが未登録である場合、事業部／サポート部門５に登録を督促することができる。なお、後述するが、ＲＡＩＤ装置１のような装置では、既知障害は、サービスプロセッサ１２により障害原因、保守手順などが登録される。未知障害の場合は、参照データがないので、事業部／サポート部を介して障害原因、保守手順などが登録される。
【００２１】
図２の障害履歴Ａは、ＲＡＩＤ装置１のような装置あるいはフィールドにおいて、保守員が障害を登録する障害履歴である。障害履歴Ａは、保守員の作業履歴データベースに格納される。障害履歴Ｂは、開発／評価部門の障害データベース３１に格納される障害履歴である。障害履歴Ｃ、製造工場４では障害データベース４１をに格納される障害履歴である。
【００２２】
障害履歴Ａ〜Ｃには、それぞれのキー番号、障害が発生した日時、ユーザ名、障害の事象などが記録されている。メンテナンスデータ管理センタ２では、障害履歴Ａ〜Ｃを監視し、キー番号が追加されると、メンテナンスデータベース２１に追加されたキー番号のデータを登録する。
【００２３】
事業部／サポート部門５は、各所で発生した未知障害に対して、障害原因を特定できるログ情報、障害原因、障害を復旧した手順などのメンテナンスデータをメンテナンスデータベース２１にＥメールあるいはＷｅｂフォームにより登録する。
【００２４】
登録監視機能は、事業部／サポート部門５に対して、定期的に例えば毎日、未知障害に対する未登録のメンテナンス作業結果に関するデータについて登録の催促を行う。登録を催促することにより発生した障害に対するメンテナンス作業結果の未登録を解消することができる。
【００２５】
メンテナンスデータ管理センタ２は、事業部／サポート部門５からの作業結果に基づいて、例えば１週間ごとに発生した障害とその対策についての統計あるいは分析などを関係各所に配信することもできる。
【００２６】
図３は、メンテナンスデータベースに格納される各種資料を登録するサブテーブルを説明する図である。
【００２７】
故障した部品の品質情報、故障解析結果、および顧客への報告などの技術資料は、保守作業やサポート作業に有用である。メンテナンスデータベース２１のサブテーブル２１１により、これらの技術資料をメンテナンスデータ管理センタに登録しておくことができる。
【００２８】
資料ごとに資料番号が与えられ、当該資料の検索のための分類、キーワード、資料が作成された対象であるメンテナンスデータベースの番号、格納場所を示すアドレスが格納される。サブテーブルの対象メンテナンスデータベースの番号によって、メンテナンスデータベースの当該番号にリンクされる。
【００２９】
ＲＡＩＤ装置１の保守作業に際して、保守手順や被疑個所の提示のほか、障害事象や故障部品が既知のものであれば、関連する資料のリンクも合わせて表示する。したがって、保守員は、キーワード等を用いて資料を検索する必要がない。ＲＡＩＤ装置１の保守員は現場で、メンテナンス管理センタ２から必要資料を入手できるので、早期に顧客報告を行うことができる。また、事業部における報告に際しても、メンテナンスデータベースの番号やキーワードから必要資料を入手することができる。さらに、品質資料も入手することができるので、保守員は、装置の全体品質と保守員が担当する装置との間に品質のずれがないかを監視でき、現場から事業部に的確に問題提起することもできる。
【００３０】
図４、５は、図１に示す装置メンテナンスシステムの動作のフローを示す図である。
【００３１】
ＲＡＩＤ装置１で障害が発生する（Ｓ１）と、まずリモートメンテナンスセンタ７に障害の発生が通知される（Ｓ２）。リモートメンテナンスセンタ７に通知された障害は、既知障害データベース７１に蓄積されているデータと比較される（Ｓ３）。発生した障害と同一事例が既知障害データベース７１に見つかれば既知障害と判断して、リモートメンテナンスセンタ７は事業部／サポート部門５に既知障害の発生を通知する（Ｓ４）。発生した障害が既知障害であると、後に詳しく説明するようにＲＡＩＤ装置１側の保守員が適正に処理することができるので、事業部／サポート部門５ではサポート要員の派遣などの特別の対応はしない。事業部／サポート部門５は、メンテナンスデータ管理センタ２に今回の既知障害の発生を登録する（Ｓ５）。
【００３２】
ＲＡＩＤ装置１で発生した障害が、既知障害データベース２１に格納されている既知障害と一致しない場合未知の障害と判断されるので、リモートメンテナンスセンタ７は未知の障害の発生を事業部／サポート部門５に報告する（Ｓ６）。発生した障害が未知の障害であるので、事業部／サポート部門５は、事業部員あるいはサポート部員を現場に急行させ、現場の保守員とともに復旧にあたることを含む特別なバックアップ体制をとる（Ｓ７）。また、事業部／サポート部門５は、メンテナンスデータ管理センタに未知障害の発生を登録する（図５：Ｓ８）。なお、事業部とサポート部門は一体となって障害に対応してもよいし、まずサポート部門が対応し、サポート部門で解決が付かない場合に事業部が対応するということでもよい。
【００３３】
未知の障害に対して保守作業が行われると、ＲＡＩＤ装置１から、保守作業の実施とその結果すなわち成功か否かがメンテナンスデータ管理センタ２へ通知される（Ｓ９）。
【００３４】
メンテナンスデータ管理センタ２では、障害が発生するたびに保守作業の成否がカウントされ、統計情報として蓄積されている。したがって、得られた通知された保守作業の実施とその結果を、登録されている他のデータとともに分析することができる。分析結果は、同様な障害が発生した場合の保守作業を選択する場合などに活用する。例えば多くの保守作業のうち成功した回数の多い保守作業の優先順位を上げてゆき、第１の優先順位の手順を最適手順とすることができる。分析の結果、保守手順あるいは被疑個所に変更があれば、メンテナンスデータベースを更新する（Ｓ１０）。
【００３５】
メンテナンスデータベース２１が更新されると、メンテナンスデータ管理センタ２からリモートメンテナンスセンタ７へ更新データがアップロードされ、リモートメンテナンスセンタ７の既知障害データベース７１は更新される（Ｓ１１）。この結果、既知障害データベース７１は常に最新の状態を維持する。
【００３６】
ＲＡＩＤ装置１は、定期的にメンテナンスデータ管理センタ２より最新のメンテナンスデータをダウンロードして、保持するメンテナンス情報を常に最新のものとする（Ｓ１２）。
【００３７】
未知の障害が解決し新規にメンテナンスデータが作成された場合は、緊急性が高いので、メンテナンスデータ管理センタ２は、リモートメンテナンスセンタ７から取得する接続装置データを基に、システムに接続されているすべての装置に対してメンテナンスデータを一斉配信することもできる。
【００３８】
図６は、ＲＡＩＤ装置１のＲＡＩＤコントローラ１１とサービスプロセッサ１２を説明する図である。サービスプロセッサ１２は、ＲＡＩＤ装置１とは独立して動作する。サービスプロセッサ１２は、インターネットを介してメンテナンスデータ管理センタ２およびリモートメンテナンスセンタ７（図１参照）に接続するともに、ＲＡＩＤ・ＣＰＵインタフェース１２７を介してＲＡＩＤコントローラ１１に接続している。さらに、サービスプロセッサ１２は、ログを格納するハードディスク１２９を備える。
【００３９】
ＲＡＩＤ装置を制御するＲＡＩＤコントローラ１１は、ボード上に搭載されたＲＡＩＤ−ＣＰＵ１３、メインメモリ１５と、サービスプロセッサ１２に対する通信のためのＳＶＰインタフェース１７を有している。メインメモリ１５は、ＲＡＩＤ装置を制御するためのファームウェアと、ＲＡＩＤ装置１の保守のためのメンテナンスデータと、アプリケーションなどに用いられるユーザデータが格納される。ＲＡＩＤコントローラ１１は、ＳＶＰインタフェース１７を介して、サービスプロセッサ１２に接続される。
【００４０】
ＲＡＩＤコントローラ１１は、データおよびログを記録するハードディスク１９に接続され、ＲＡＩＤ・ＣＰＵ１３によってハードディスク１９に格納されたデータおよびログにアクセスすることができる。ログは、ＲＡＩＤ装置１の処理の記録であり、障害の原因を究明するときなどに参照される。ログはハードディスク１９に記録されているので、ログを格納する容量に心配はなく、長期にわたってすべてのログを残しておくことができる。図６では、データを格納するハードディスクとログを格納するハードディスクを別個に示すが、単一のハードディスクであってもよい。
【００４１】
さらに、ＲＡＩＤ装置１は表示部１８を備え、表示部１８にはＲＡＩＤコントローラ１１あるいはサービスプロセッサ１２による障害原因および保守手順あるいはログ解析結果を表示することができる。表示部１８は、ＲＡＩＤ装置１のコンソールや保守端末でもよく、さらに保守員の携帯電話等の携帯端末の表示画面でもよい。
【００４２】
図７は、サービスプロセッサの機能を説明する図である。サービスプロセッサ１２の制御素子であるマイクロプロセッサ（ＭＰＵ）１２１が、サービスプロセッサ１２を構成する素子間のデータ管理を行うチップセット１２４を介して、フラッシュＲＯＭ（Read Only Memory）１２２およびメモリ１２３と接続されている。チップセット１２４は、一方ではインターネットインタフェース１２５に接続され、他方ではバスブリッジ１２６を介して、ＲＡＩＤ・ＣＰＵインタフェース１２７に接続される。チップセット１２４はさらに、ハードディスクドライブ・インタフェース１２８を介して、ログ保存用のハードディスク１２９に接続される。
【００４３】
サービスプロセッサ１２は、インターネットインターフェース２５を介してインターネットに接続し、メンテナンスデータ管理センタ２やリモートメンテナンスセンタ７に対してデータの送受信が可能である。また、サービスプロセッサは、ＲＡＩＤ・ＣＰＵインタフェース１２７を介してＲＡＩＤコントローラ１１に対してデータの送受信が可能である。
【００４４】
サービスプロセッサ１２のフラッシュＲＯＭ１２２には、サービスプロセッサ１２用のファームウェアが格納されている。メモリ１２３は、サービスプロセッサ用ファームウェアの動作を行うためのデータを格納している。また、メモリ１２３は、サービスプロセッサとＲＡＩＤ・ＣＰＵとの間で送受信されるデータのキャッシュとして動作し、さらにメンテナンスデータ管理センタ２からの受信データのバッファとしても動作する。ＲＡＩＤコントローラ１１のログは、ＲＡＩＤ・ＣＰＵインタフェース１２７、ハードディスクドライブ・インタフェース１２８を経由してハードディスク１２９に転送され、蓄積される。したがって、ＲＡＩＤコントローラ１１がダウンしたときも、直前までのログはハードディスク１２９に格納される。したがって、サービスプロセッサ１２がＲＡＩＤ装置とは独立して動作することにより、ダウンしたＲＡＩＤ装置のログを解析することができる。
【００４５】
図８、９は、装置に発生した障害を当該装置により保守する際の処理を示すフローである。
【００４６】
サービスプロセッサ１２は定期的に、メンテナンスデータ管理センタ２にアクセスして、メンテナンスデータに追加あるいは変更があるか否かを判定する。メンテナンスデータに追加あるいは変更があれば、追加あるいは変更分すなわちメンテナンスデータの差分データをメモリ１２３にダウンロードする（Ｓ２１）。
【００４７】
ダウンロードされるメンテナンスデータには、事業部や工場で障害の起きた製品を診断して判明した故障モードと故障素子データ、さらにＲＡＩＤ装置１および装置メンテナンスシステム１０に接続される他のＲＡＩＤ装置で発生した障害に関する故障モードと故障素子データが含まれている。また、障害検出論理に関係する障害の重みあるいは障害判定の閾値などの変更があった場合も、メンテナンスデータとしてダウンロードされる。
【００４８】
ダウンロードした後、サービスプロセッサの制御データなどサービスプロセッサ１２専用のメンテナンスデータがあれば、フラッシュＲＯＭ１２２へ書き込む。
【００４９】
サービスプロセッサでの処理が終了すれば、サービスプロセッサは、ＲＡＩＤ・ＣＰＵインタフェース１２７を介して、ダウンロードされたデータをＲＡＩＤコントローラ１１に転送する（Ｓ２２）。
【００５０】
転送されたデータは、ＲＡＩＤ処理に影響を与えるデータではないので、ＲＡＩＤコントローラ１１が活性の状態で、ＲＡＩＤコントローラ１１のメインメモリ１５のメンテナンスデータ領域に展開される。なお、エラー判定論理に変更が合った場合も、メンテナンスデータ領域に展開されて機能する。この結果、ＲＡＩＤ装置１が稼働中にエラー処理論理を更新することができるので、常に最新のエラー処理論理を使用することができる。なお、旧データが不要になった場合は、その領域をユーザデータ領域として開放する。
【００５１】
サービスプロセッサ１２側では、メンテナンスデータとしてダウンロードされているログ解析論理に従って、ハードディスク１２９に転送されているＲＡＩＤコントローラのログについて解析を行う（Ｓ２３）。次いで、サービスプロセッサ１２は、ログ解析で得られた統計、保守履歴、ログ解析結果を、ハードディスク１２９に格納する（Ｓ２４）。
【００５２】
エラーイベントが発生する（Ｓ２５）と、ＲＡＩＤコントローラ１１では、メインメモリ１５のメンテナンスデータ領域にあるイベント処理関数がファームウェアからコールされて、新しいエラー処理論理によりエラーが判定され、一次処理結果を得る（Ｓ２６）。
【００５３】
ダウンロードされるメンテナンスデータには、これまでのすべての障害について故障モードデータと故障素子データが含まれている。したがって、ＲＡＩＤ装置１で発生した障害が既知障害であれば、ＲＡＩＤコントローラ１１は、得られた一次処理結果により故障部品を判定することができる（Ｓ２７）。ここで、故障素子とは、部品に含まれる電子素子をいい、故障部品とは、素子を含む故障モジュールをいう。
【００５４】
他方、サービスプロセッサ１２は、エラーの発生に伴い追加されたログを解析する（Ｓ２８）。ログ解析の結果およびメンテナンススデータにより、サービスプロセッサ１２は、ＲＡＩＤ・ＣＰＵ１３の一次処理結果の妥当性をチェックする（Ｓ２９）。これにより、ＲＡＩＤ・ＣＰＵ１３の判定結果を補完することができ、精度を上げることができる。
【００５５】
故障部品が特定されると、ＲＡＩＤ・ＣＰＵ１３は、メンテナンスデータに基づいて交換手順を出力し、表示部１８に提示する（Ｓ３０）。ＲＡＩＤ装置の保守員は、表示部１８に表示された手順に従って最適なメンテナンスを実行することができる（Ｓ３１）。
【００５６】
ＲＡＩＤ・ＣＰＵ１３は、特定された故障モードと故障素子について、システム構成情報や障害のクリティカル度を考慮して、装置の冗長度・信頼度が充分高いと判断すると、ＲＡＩＤ装置１が活性の期間に保守する必要がないとして、ＲＡＩＤ装置を停止した後の保守手順も選択肢として表示装置１８に提示する。この場合、保守員は、装置に影響を与えるリスクが少ない装置停止後の保守を選択することができる。
【００５７】
メンテナンスが終了すると、エラーの重大度を示すエラー重度、あるいはエラーに応じた重みを加算して作られる統計加点などのエラー処理判定結果がファームウェアへコールバックされる。さらに、ＲＡＩＤコントローラ１１は、作業が成功したか、失敗したかを含む保守作業結果をサービスプロセッサ１２に送信し、サービスプロセッサ１２は、メンテナンスデータ管理センタへフィードバック情報として保守作業結果を通知する（Ｓ３２）。
【００５８】
最後に、本システムでは、最新のメンテナンスデータで故障素子を特定することができ、関連資料も参照できるので、後日の検討を待つ必要がない。したがって、保守員は、その場でユーザへの初期報告を作成することができる（Ｓ３３）。
【００５９】
図１０は、サービスプロセッサ１２の平常時のログ解析のフローを示す図である。
【００６０】
ＲＡＩＤ装置１から独立しているサービスプロセッサ１２は、ＲＡＩＤ装置１が稼動中に、ダウンロードされた最新のメンテナンスデータを参照して、ＲＡＩＤ装置１の内部ログを解析することができる。
【００６１】
まず、サービスプロセッサ１２は、ＲＡＩＤ装置１が正常に稼働中に、ハードディスク１２９が保持している今までのログを解析し、障害履歴や部品交換履歴を抽出する（Ｓ４１）。
【００６２】
次に、抽出された障害履歴や部品交換履歴のある部品と現在稼動中の部品とを照らしあわせる（Ｓ４２）。その結果、障害履歴のある部品あるいは所定期間以上交換されていない部品が発見されると、障害予防のための交換対象としてＲＡＩＤコントローラ１１に通知する（Ｓ４３）。
【００６３】
さらに、複数の部品に関係する故障が発生していた場合で複数の部品のうちに未交換部品がある場合も、未交換部品を予防交換対象としてＲＡＩＤコントローラ１１に通知する（Ｓ４４）。
【００６４】
本実施形態によれば、顧客の装置にとっては新規な障害でも、開発部門や製造工場で既知の障害であれば、ダウンロードされるメンテナンスデータを用いて故障モードと故障素子を容易に特定することができる。また、マニュアル化しにくい保守手順であってもマニュアル化されている保守手順と同様、故障部品の交換手順を装置のコンソールや保守端末あるいは保守員の携帯端末へ出力し、保守員は最適な手順に従って作業ができる。
【００６５】
装置から独立しているサービスプロセッサにより最新のメンテナンスデータを参照して装置の内部ログを解析するので、平常時の正確な障害予兆解析が可能である。さらに、ＲＡＩＤ装置がダウンしてＲＡＩＤ−ＣＰＵによるエラー処理が行われない場合でも、サービスプロセッサがログ解析を行うことにより障害部品を特定することができる。ログもハードディスクに格納されるので、長期間のログを蓄積することができる。
【００６６】
また、インターネットあるいは他の通信回線を介してセンタに問合せをして故障部品を特定するのでなく、装置側にデータをダウンロードして装置側で判断するので、迅速な対応が可能である。
【００６７】
本システムにおいては、装置は保守イベント毎にメンテナンスデータ管理センタへ保守成功あるいは失敗の結果を送信することで、成功事例と失敗事例を同時に集約し、即時にメンテナンスデータへ反映することができる。
【００６８】
本システムでは、すべての既知障害データが集中管理され、個々の装置に配信されるので、障害の実績データからの統計情報、および技術的分析による推測、さらには保守作業のノウハウが短期間で反映される。したがって、故障部品の特定が困難な複数の部品間の障害であっても、故障発生時において最適な保守作業を提示することができる。
【００６９】
以上の実施形態に関し、さらに以下の付記を開示する。
（付記１）
第１の制御部と該第１の制御部とは独立した第２の制御部を備える装置と、
前記装置のメンテナンスデータを管理するメンテナンスデータ管理サーバと、
を備え、
前記第２の制御部は、前記メンテナンスデータ管理サーバから前記メンテナンスデータをダウンロードして前記第１の制御部に転送し、前記第１の制御部から転送されるメンテナンス結果を前記メンテナンスデータ管理サーバに送信する装置メンテナンスシステム。
（付記２）
前記第１の制御部は、前記転送されたメンテナンスデータに基づいて、メンテナンスの手順を生成する付記１に記載の装置メンテナンスシステム。
（付記３）
前記第２の制御部は、装置の障害の過去ログを解析し、装置の部品の障害履歴を抽出し、部品の障害発生を予測する付記２に記載の装置メンテナンスシステム。
（付記４）
前記メンテナンスデータ管理サーバから既知障害データを受信する既知障害データベースを有するリモートメンテナンス・サーバを備え、前記装置で障害が発生すると、前記リモートメンテナンス・サーバに通知され、リモートメンテナンス・サーバで既知障害データとの比較が行われ、既知の障害か未知の障害かが判定される付記１〜３のいずれか１項に記載の装置メンテナンスシステム。
（付記５）
前記メンテナンスデータ管理サーバは、ネットワークを介して接続された障害データベースにアクセスして障害データを収集する付記１〜４のいずれか１項に記載の装置メンテナンスシステム。
（付記６）
第１の制御部と該第１の制御部とは独立した第２の制御部を備える装置と、
前記装置のメンテナンスデータを管理するメンテナンスデータ管理サーバと、
を備える装置メンテナンスシステムの装置メンテナンス方法であって、
前記第２の制御部は、前記メンテナンスデータ管理サーバから前記メンテナンスデータをダウンロードして前記第１の制御部に転送し、
前記第１の制御部は、前記メンテナンスデータに基づいてメンテナンス手順を生成し、  前記第１の制御部は、メンテナンス終了後、メンテナンス結果を前記第２の制御部に転送し、
前記第２の制御部は、転送された前記メンテナンス結果を前記メンテナンスデータ管理サーバに送信する装置メンテナンス方法。
（付記７）
前記第２の制御部は、装置の障害の過去ログを解析し、装置の部品の障害履歴を抽出し、部品の障害発生を予測する付記６に記載の装置メンテナンス方法。
【図面の簡単な説明】
【００７０】
【図１】実施形態である装置メンテナンスシステムを示す図である。
【図２】メンテナンスデータ管理センタの登録監視機能を説明する図である。
【図３】メンテナンスデータベースに格納される各種資料を登録するサブテーブルを説明する図である。
【図４】装置メンテナンスシステムの処理（その１）を説明する図である。
【図５】装置メンテナンスシステムの処理（その２）を説明する図である。
【図６】ＲＡＩＤ装置のＲＡＩＤコントローラとサービスプロセッサとの関係を説明する図である。
【図７】サービスプロセッサの構成の概要を説明する図である。
【図８】サービスプロセッサとＲＡＩＤコントローラの動作のフロー（その１）を示す図である。
【図９】サービスプロセッサとＲＡＩＤコントローラの動作のフロー（その２）を示す図である。
【図１０】サービスプロセッサの平常時のログ解析の処理フローを示す図である。
【符号の説明】
【００７１】
１０    装置メンテナンスシステム
１    ＲＡＩＤ装置
１１    ＲＡＩＤコントローラ
１２    サービスプロセッサ
１８    表示部
１９    ハードディスク
２    メンテナンスデータ管理センタ
３    開発評価部門
４    製造工場
５    事業部／サポート部門
７    リモートメンテナンスセンタ
【図１】
0004648961.tif 000002
【図２】
0004648961.tif 000003
【図３】
0004648961.tif 000004
【図４】
0004648961.tif 000005
【図５】
0004648961.tif 000006
【図６】
0004648961.tif 000007
【図７】
0004648961.tif 000008
【図８】
0004648961.tif 000009
【図９】
0004648961.tif 000010
【図１０】
0004648961.tif 000011