(57)【要約】      （修正有）【課題】コストのかかる機器を追加することなく、人の操作による手間をかけることもなく、サーバ装置で使用しているＯＳの種類に制限されることもなく、予め設定したサーバ装置を使用していない時間帯にファームウェアを自動更新する。【解決手段】ファームウェアを内部に有する情報処理装置のファームウェア更新方法。情報処理装置はその基本動作及び管理ＬＡＮに対する入出力動作を制御するコントローラと、その初期動作を制御するＢＩＯＳを備え、コントローラは管理ＬＡＮを介して情報処理装置を管理する管理端末の更新管理プログラムと連携して機能する仮想メディアを有する。管理端末の更新管理プログラムは情報処理装置のファームウェアを更新する更新プログラムを配信サーバからダウンロードし、コントローラは管理端末にダウンロードされた更新プログラムを仮想メディア上で起動し、その更新プログラムが情報処理装置のファームウェアを更新する。【選択図】図１
2015060411.tif 000002
【特許請求の範囲】
【請求項１】
ファームウェアを内部に有する情報処理装置のファームウェア更新方法であって、前記情報処理装置は当該情報処理装置の基本動作及び管理ＬＡＮに対する入出力動作を制御する第１のコントローラと当該情報処理装置の初期動作を制御するＢＩＯＳを備え、前記第１のコントローラは前記管理ＬＡＮを介して当該情報処理装置を管理する管理端末の更新管理プログラムと連携して機能する仮想メディアを有し、前記管理端末の更新管理プログラムは当該情報処理装置のファームウェアを更新するファームウェア更新プログラムを配信サーバからダウンロードし、前記第１のコントローラは前記管理端末にダウンロードされた前記ファームウェア更新プログラムを前記仮想メディア上で起動し、前記仮想メディア上で起動した前記ファームウェア更新プログラムが当該情報処理装置のファームウェアを更新することを特徴とする情報処理装置のファームウェア更新方法。
【請求項２】
前記管理端末の更新管理プログラムは前記ファームウェア更新プログラムを前記配信サーバからダウンロードした後に前記ＬＡＮを介して前記第１のコントローラ内の更新要求フラグをセットし、当該情報処理装置に再起動がかけられた際、前記ＢＩＯＳは前記第１のコントローラ内の更新要求フラグの状態を取得し、前記更新要求フラグがセットされていた場合に前記仮想メディアから前記ファームウェア更新プログラムを起動することを特徴とする請求項１記載の情報処理装置のファームウェア更新方法。
【請求項３】
前記管理端末の代わりに所定のサーバ装置を用意し、前記サーバ装置は当該サーバ装置の基本動作及び前記管理ＬＡＮに対する入出力動作を制御する第２のコントローラを備え、前記更新管理プログラムは前記第２のコントローラで動作することを特徴とする請求項１又は２に記載の情報処理装置のファームウェア更新方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はソフトウェアプログラムによって更新可能なファームウェアを内部に有するサーバ装置に関するものである。
【背景技術】
【０００２】
昨今、基幹業務で多く使われているブレードサーバやＰＣサーバはＩｎｔｅｌのＩＡ−３２、ＩＡ−６４のアーキテクチャを採用しＩＡサーバと呼ばれている。これらのＩＡサーバはＯＳとしてＷｉｎｄｏｗｓ(登録商標)またはＬｉｎｕｘ（登録商標）を採用しているものが主流となっている。ＩＡサーバはサーバシステム装置のプロセッサ、メモリを利用して動作するファームウェアであるＢＩＯＳ（Ｂａｓｉｃ  Ｉｎｐｕｔ  Ｏｕｔｐｕｔ  Ｓｙｓｔｅｍ）と、サーバシステム装置のプロセッサ、メモリとは別の独立した専用のプロセッサ、メモリを使用して動作可能なＢＭＣ（Ｂａｓｅｂｏａｒｄ  Ｍａｎａｇｅｍｅｎｔ  Ｃｏｎｔｒｏｌｌｅｒ）ファームウェアを内部に有しているのが一般的である。これらのファームウェアは外部から実行されるファームウェア更新プログラムにてファームウェアプログラムコードを更新可能である。また上記のＢＩＯＳ、ＢＭＣのファームウェアの他にＩＡサーバ内部に接続されている例えばＲＡＩＤボードなどの内蔵デバイスが更新可能なファームウェアを有している場合もある。
【０００３】
不具合の改善や、機能のエンハンスの為にＢＩＯＳ、ＢＭＣ、またはその他の内蔵デバイスのファームウェアを外部のファームウェア更新プログラムから更新する機会が増えてきており、サーバの装置ベンダー、サーバユーザともに手間無く、安価に、安全にファームウェアを更新する汎用的な仕組みの必要性が高まってきている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１２−２０３４４２号公報
【特許文献２】特開２００９−１９３４５３号公報
【特許文献３】特開２００６−０３１３１２号公報
【特許文献４】特開２０１１−１４５９１０号公報
【特許文献５】特表２００５−５０２９７１号公報
【特許文献６】特開２００３−３３０６５５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ファームウェアを更新するファームウェア更新プログラムは、そのソフトウェア自体がどのＯＳ上で動作可能かの使用条件が異なる、サーバユーザの使用しているＯＳがＷｉｎｄｏｗｓかＬｉｎｕｘかあるいは他のＯＳか不定であるため、ファームウェア更新プログラムを提供するサーバ装置ベンダーがファームウェア更新プログラムを複数種類準備しなければならず、手間がかかるという問題がある。
この問題を解決する為にＣＤ（Ｃｏｍｐａｃｔ  Ｄｉｓｋ）やＦＤ（Ｆｒｏｐｐｙ  Ｄｉｓｋ）から自己起動するＭＳ−ＤＯＳなどのＯＳ上でファームウェア更新プログラムを実行する方法が考えられるが、この方法ではサーバ装置を人が操作してファームウェア更新プログラムを実行しなければならず、例えば深夜や早朝などのサーバシステムが使われていない時間帯に自動でファーウェアを更新するという事ができず手間がかかるという問題がある。
【０００６】
サーバ装置のＯＳにファームウェア更新プログラムが依存してしまう、また深夜などの時間帯に自動で更新できないというこれらのどちらの問題も解決するファームウェア更新手段として特許文献１特許文献２、特許文献３、特許文献４の公知例ではエンクロージャーマネージャーボードなどの専用ボードを利用して、サーバ装置が電源オフ状態でも動作可能なＢＭＣにエンクロージャーマネージャーから命令を送り、サーバ装置を使用していない時間帯、またはサーバ装置使用中でも稼動を殆ど停止することなく、またシステム装置のＯＳの種類に依存する事も無くファームウェアを更新する方法が提案されている。
【０００７】
しかしながらこれらの特許文献１、特許文献２、特許文献３、特許文献４の公知例の方法ではサーバ装置内部にエンクロージャーマネージャーボードなどマネージメントボードを有する必要があり、装置コストが高くなるという問題がある。
【０００８】
特許文献５、特許文献６の様に通信機器や画像形成装置ではネットワーク通信を利用して、特に機器を追加する事無く、またユーザの使用を阻害することなくファームウェアを更新する方法が提案されているが、これらの方法が可能な前提は通信機器や画像形成装置の装置提供元がＯＳの提供元でもあることであり、ＷｉｎｄｏｗｓやＬｉｎｕｘなど一般的に販売されているＯＳを使用するＩＡサーバ装置では同様の方法を使用する事は困難である。
【０００９】
またエンクロージャーマネージャーボードなどの専用ボードを使用する特許文献１、特許文献２、特許文献３、特許文献４の方法では、サーバシステム装置のＯＳに依存せずにファームウェアを更新できるものの、一般的にエンクロージャーマネージャーボードに対し実行命令を送る管理端末を用意しなければならないという煩わしさがある。この管理端末はサーバ装置ベンダーではなくサーバユーザで用意する必要がある。つまりサーバ装置ベンダーから見るとサーバユーザに手間をとらせてしまうという問題がある。
【課題を解決するための手段】
【００１０】
ファームウェアを内部に有する情報処理装置のファームウェア更新方法であって、前記情報処理装置は当該情報処理装置の基本動作及び管理ＬＡＮに対する入出力動作を制御する第１のコントローラと当該情報処理装置の初期動作を制御するＢＩＯＳを備え、前記第１のコントローラは前記管理ＬＡＮを介して当該情報処理装置を管理する管理端末の更新管理プログラムと連携して機能する仮想メディアを有し、前記管理端末の更新管理プログラムは当該情報処理装置のファームウェアを更新するファームウェア更新プログラムを配信サーバからダウンロードし、前記第１のコントローラは前記管理端末にダウンロードされた前記ファームウェア更新プログラムを前記仮想メディア上で起動し、前記仮想メディア上で起動した前記ファームウェア更新プログラムが当該情報処理装置のファームウェアを更新する。
【発明の効果】
【００１１】
サーバユーザが使用しているＯＳの種類に依存することなく、またサーバユーザがサーバシステムを使用していない深夜などの時間帯を利用した自動実行が可能で、エンクロージャーマネージャーボードなどコストアップする機器を追加することなく、ファームウェアを更新することができる。
【図面の簡単な説明】
【００１２】
【図１】本発明の第１の実施例の概略図である。
【図２】第１の実施例のアップデート要求時の概略図である。
【図３】第１の実施例のサーバ装置再起動時の概略図である。
【図４】第１の実施例のアップデート開始時の概略図である。
【図５】第１の実施例の仮想メディア動作時の概略図である。
【図６】本発明の第２の実施例の概略図である。
【図７】アップデートツールイメージデータの概略図である。
【図８】ＢＭＣの概念図である。
【図９】フラッシュＲＯＭのコードのＲＡＭへのシャドウを説明する図である。
【図１０】ＢＭＣファームウェア更新プログラムの動作を説明する図である。
【図１１】第２の実施例の他のサーバ装置のＢＭＣのＲＡＭの構成図である。
【発明を実施するための形態】
【００１３】
図１を用いて本発明の第１の実施例の概略を説明する。配信サーバ１００はファームウェアの提供元であるサーバ装置ベンダーが更新されたアップデートツールイメージデータ１０４をアップロード可能なサーバである。アップデートツールイメージデータ１０４の内部の構成の詳細は図７を用いて後で説明する。
【００１４】
管理端末１０１は管理対象サーバ装置１０２を管理する為の端末装置である。管理端末１０１の内部のＨＤＤ１０５はアップデートツールマネージャーソフトウェア１０６を内部に有している。
【００１５】
管理対象サーバ装置１０２はアップデート対象となるファームウェア１１０を内部に有するサーバ装置である。管理対象サーバ装置１０２の内部には、本発明の方法を実行するプログラムコードを持つＢＭＣ１０７、ＢＩＯＳ１１１を有している。ＢＭＣ１０７は管理用のＬＡＮ１０８を持ち、この管理用ＬＡＮ１０８を経由して管理端末１０１のアップデートマネージャーソフトウェア１０６と通信する。仮想メディア１０９はＢＭＣ１０７によって物理的には存在していないＣＤドライブを擬似的に管理対象サーバ装置１０２に存在しているかの様に見せる機能である。
【００１６】
本発明の方法ではファームウェアの更新があると、新しいファームウェアのアップデートツールイメージデータ１０４が配信サーバ１００にアップロードされ、配信サーバ１００を定期的に監視している管理端末１０１上のＨＤＤ１０５内のアップデートマネージャーソフトウェア１０６がそのアップデートツールイメージデータ１０４をダウンロードし、その後管理対象サーバ装置１０２のＢＭＣ１０７に管理ＬＡＮ１０８経由でコマンドを発行し、ＢＭＣ１０７内部の更新要求有りを意味するフラグを１にセットする。その後、管理対象サーバ装置１０２がサーバユーザの指定により手動または自動で再起動した際にＢＩＯＳ１１１がＢＭＣ１０７にコマンドを発行しフラグの状態を取得し、もし更新要求があればＢＭＣ１０７によって擬似的に存在している仮想メディア１０９から起動させる。アップデートマネージャーソフトウェア１０６がダウンロードしたアップデートツールイメージデータ１０４は仮想メディア１０９で起動可能なメディアのイメージデータである。仮想メディア１０９上で実行されたアップデートプログラムは更新対象となるファームウェア１１０を更新する。更新対象の全てのファームウェア１１０が更新完了すると、管理対象サーバ装置１０２を再起動する。
【００１７】
次に図２、図３、図４、図５を用いて第１の実施例をより詳細に説明する。
【００１８】
図２における配信サーバ１００には、ファームウェアを提供する提供元が更新されたアップデートツールイメージデータ１０４を登録する。このイメージデータは管理対象サーバ装置１０２上にて電源ＯＮの状態から起動可能なアップデートツールをＩＳＯイメージ化したデータである。このアップデートツールイメージデータ１０４の内部の構成の詳細は図７を用いて後で説明する。
【００１９】
管理端末１０１上にあるアップデートマネージャーソフトウェア１０６は定期的に配信サーバ１００にアクセスし、新しいアップデートツールイメージデータ１０４が配信サーバ１００に登録されたかを監視している。第１の実施例ではアップデートマネージャーソフトウェア１０６が配信サーバ１００を定期的に監視するとしたが、配信サーバ１００側からアップデートマネージャーソフトウェア１０６に通知する方式としてもよい。
【００２０】
新しいアップデートツールイメージデータ１０４が配信サーバ１００に登録された時、アップデートマネージャーソフトウェア１０６は新しいアップデートツールイメージデータ１０４を配信サーバ１００からダウンロードする（ステップ２０）。このアップデートツールイメージデータ１０４はＢＭＣ１０７の仮想メディア機能を利用して管理対象サーバ装置１０２上で動作可能なものであるが、この動作の詳細に関しても図７を用いて後で説明する。
【００２１】
アップデートマネージャーソフトウェア１０６は管理対象サーバ装置１０２のＢＭＣ１０７の持つ管理ＬＡＮ１０８とＬＡＮで接続されており、ＩＰＭＩｏｖｅｒＬＡＮを用いてＩＰＭＩコマンドでＢＭＣ１０７にコマンドを発行し、ＢＭＣ１０７内部のフラグをセット／クリア、またフラグの状態を取得することが可能である。
【００２２】
下記表１にＢＭＣ１０７内部のフラグを示す。
【００２３】
【表１】
2015060411.tif 000003
【００２４】
アップデートマネージャーソフトウェア１０６は管理対象サーバ装置１０２のＢＭＣ１０７にＩＰＭＩコマンドを発行し、更新要求があった事を示すフラグUP_REQUEST[xx]を１にセットする。本フラグは配列であり、ＸＸは管理対象サーバ装置１０２内の更新可能なファームウェアの種類が入る。またアップデートマネージャーソフトウェア１０６はシステム装置に再起動がかけられた事を示すフラグSYSTEM_REBOOTとファームウェアアップデートプロセス中である事を示すフラグFW_UPDATE_PROCESSは０にクリアし初期化する（ステップ２１）。
【００２５】
図２に示した動作は配信サーバ１００に更新されたアップデートツールイメージデータ１０４が登録された際の動作であるが、本発明の方法ではこのタイミングでファームウェアアップデートを即時に行なうわけではない。このタイミングでは更新要求があった事を示すフラグUP_REQUEST[xx]をセットするのみである。実際にファームウェアアップデートが開始するのは、サーバユーザが次回に管理対象サーバ装置１０２を手動または自動で再起動した契機である。従ってもし管理対象サーバ装置１０２を深夜に自動で再起動する様に設定していた場合には深夜に自動でファームウェアのアップデートを行う事ができる。
【００２６】
図３は手動または自動で管理対象サーバ装置１０２が再起動した際の動作図である。
【００２７】
アップデートマネージャーソフトウェア１０６はファームウェアがアップデートプロセスに入った事を示すフラグFW_UPDATE_PROCESSがＢＭＣ１０７によって１にセットされるかを、ＩＰＭＩｏｖｅｒＬＡＮのコマンドで定期的に監視している（ステップ３１）。
【００２８】
通常ＢＭＣ１０７は電源監視機能を持ち管理対象サーバ装置１０２に再起動(システムリセット)がかけられた事は自己検知できるため、もしＢＭＣ１０７が管理対象サーバ装置１０２の再起動を検知したらシステム装置に再起動がかけられた事を示すフラグSYSTEM_REBOOTを１にセットする（ステップ３２）。またシステムが再起動するため、ＢＩＯＳ１１１のＰＯＳＴ（Ｐｏｗｅｒ  Ｏｎ  Ｓｅｌｆ  Ｔｅｓｔ）処理が実行される。ＢＩＯＳのＰＯＳＴ処理とはパソコンやＩＡサーバのＢＩＯＳが、システム装置電源オン時にＣＰＵやメモリ、ＰＣＩデバイスやＵＳＢデバイスやＨＤＤやＦＤＤなどのドライブが正常な状態であるか確認するテストである。
【００２９】
ＢＩＯＳ１１１のＰＯＳＴ処理の中でＩＰＭＩコマンドをＢＭＣ１０７に対して発行し、ＢＭＣ１０７内のフラグUP_REQUEST[xx]とFW_UPDATE_PROCESSの状態を取得する。この時、UP_REQUEST[xx]は１にセットされているもののFW_UPDATE_PROCESSはまだ０のままでファームウェアアップデートプロセスが開始していない状態なので、ＢＩＯＳ１１１のＰＯＳＴは一時停止し、ＯＳが起動しない状態となる（ステップ３３）。
【００３０】
次に、UP_REQUEST[xx]が１にセットされ、SYSTEM_REBOOTが１にセットされ、かつＢＩＯＳ１１１のＰＯＳＴからフラグの状態取得のＩＰＭＩコマンドが発行済みであるという３つの条件が揃ったかをＢＭＣ１０７内部の仮想メディアをコントールできるリモートコンソールの定期処理にて監視し、もしこれらの３つの条件が揃った場合には既に仮想メディアを何かが接続し利用していたら切断を行い（ステップ３４）、ファームウェアアップデートプロセスに入った事を示すフラグFW_UPDATE_PROCESSを１にセットする（ステップ３５）。
【００３１】
図３にて示す動作にてＢＩＯＳ１１１はＰＯＳＴで停止、ＢＭＣ１０７は仮想メディア接続待機状態でフラグFW_UPDATE_PROCESSが１にセットされファームウェアアップデート開始可能となる。
【００３２】
図４はFW_UPDATE_PROCESSが１にセットされた事をアップデートマネージャーソフトウェア１０６が検知した際の動作である。
【００３３】
アップデートマネージャーソフトウェア１０６はFW_UPDATE_PROCESSが１にセットされた事を検知すると（ステップ４１）、リモートコンソールを接続し（ステップ４２）、仮想メディアを接続する（ステップ４３）。その後、仮想メディア上にステップ２０で配信サーバ１００からダウンロードしたアップデートツールイメージデータ１０４を読み込み（ステップ４４）、読み込みが完了後、アップデートマネージャーソフトウェア１０６は管理対象サーバ装置１０２を強制オフオンまたはリセットをかけて再起動する（ステップ４５、４６）。ＢＩＯＳ１１１はステップ３３と同様にＢＭＣ１０７のフラグの状態を取得するＩＰＭＩコマンドをＰＯＳＴにて発行する（ステップ４７）が、今度はUP_REQUEST[xx]が１にセットされていて、さらにFW_UPDATE_PROCESSも１にセットされている。これらのフラグが両方ともセットされている場合には、ＢＩＯＳ１１１はサーバユーザのＢＩＯＳセットアップのブートオーダの優先度の設定に関わらず、強制的にＢＭＣ１０７の仮想メディアからブートをする（ステップ４８）。
【００３４】
図５はファームウェアアップデートしている段階からファームウェアアップデート完了までの動作を示す動作図である。
【００３５】
アップデートマネージャーソフトウェア１０６は前記ステップ４５、４６の後は再びFW_UPDATE_PROCESSを監視しFW_UPDATE_PROCESSが１にセットされている間は何もせずに待機し、この間は配信サーバ１００から新たに更新されたアップデートツールイメージデータ１０４を受信する事も行なわない（ステップ５１）。
【００３６】
次のステップ５２、ステップ５３は仮想メディア１０９上で実行されるアップデートツールの動作である。アップデートツールもＩＰＭＩコマンドを実行する事によりＢＩＯＳ１１１、アップデートマネージャーソフトウェア１０６と同様に表１に示すＢＭＣ１０７内部のフラグを設定参照可能である。アップデートツールはＢＭＣ１０７の内部のファームウェア更新要求があった事を示すフラグUP_REQUEST[xx]の値をチェックする。もしUP_REQUEST[xx]が１にセットされていた場合は該当ファームウェア更新プログラムを用いてファームウェアの更新を実行する（ステップ５２）。
【００３７】
該当ファームウェア更新プログラムとは例えばＢＭＣであればＢＭＣファームウェア更新プログラム、ＢＩＯＳであればＢＩＯＳファームウェア更新プログラム、ＲＡＩＤであればＲＡＩＤファームウェア更新プログラムを指す。これらの更新プログラムはファームウェアベンダーから提供されるものを使用することを想定している。例えばＢＭＣファームウェアベンダーのＡＭＩ社であればＢＭＣファームウェア更新プログラムとしてＭＳ−ＤＯＳ上で動作するyafukcs.exe、Ｌｉｎｕｘ上で動作するyafuflash、Ｗｉｎｄｏｗｓ上で動作するyafuflash.exeを提供している、またＢＩＯＳファームウェア更新プログラムとしてはもしＢＩＯＳファームウェアベンダーがＰｈｏｅｎｉｘ社であればＭＳ−ＤＯＳ上で動作するphlash.exe、Ｗｉｎｄｏｗｓ上で動作するWinPhlash.exeを提供している、またＢＩＯＳファームウェアベンダーがＡＭＩ社であればＷｉｎｄｏｗｓ上で動作するafuwin.exeやafuwinx64.exe、Ｌｉｎｕｘ上で動作するafulnx_26_32やafulnx_26_64を提供している。またＲＡＩＤファームウェア更新プログラムに関しては、もしＲＡＩＤファームウェアベンダーがＬＳＩ社であればＷｉｎｄｏｗｓ上で動作するMegaCli.exe、Ｌｉｎｕｘ上で動作するMegaCli、MegaCli64を提供している。本発明の方法ではこれらのファームウェアベンダー提供のファームウェア更新プログラムを利用する事を想定している。また上記例ではＡＭＩ社、Ｐｈｏｅｎｉｘ社、ＬＳＩ社の提供するファームウェア更新プログラムの例を挙げたが、本発明ではファームウェア更新プログラム提供元のファームウェアベンダーを上記３社に限定するものではない。またファームウェアベンダーから提供されたファームウェア更新プログラムに一部改変を加えたものや、独自に作成したファームウェア更新プログラムを利用した場合も本発明の範囲とする。またこれらのファームウェアベンダー提供のファームウェア更新プログラムは実行時にフラッシュＲＯＭに書き込むファームウェアイメージデータを最初にシステム装置やＢＭＣのＲＡＭに全て転送しＲＡＭからフラッシュＲＯＭに書き込む方式のものと、ＲＡＭには転送を行なわず、ファームウェア更新プログラムを実行するとファームウェア更新プログラムが実行しながら部分部分を直接フラッシュＲＯＭに書き込む方式のものがある。本発明の方法ではファームウェアベンダーの提供するファーウェア更新プログラムがどの様な方式でファームウェアを更新するかは限定しない。
【００３８】
ここで上記のファームウェアベンダー提供のファームウェア更新プログラムの動作の一例としてＢＭＣファームウェア更新プログラムについて図９、図１０を用いて説明する。この図９、図１０を用いて説明する技術は一般的に広く使われている公知の技術である。
【００３９】
まずは図９のＡ、図９のＢを用いて一般的なＩｎｔｅｌアーキテクチャのサーバシステムのＢＩＯＳファームウェアプログラムコードのシャドウについて説明する。
【００４０】
図９のＡはサーバシステム９０１に電源供給がされていない状態の図である。このサーバシステム９０１には内部にシステムのＣＰＵ９０３、システムのＲＡＭ９０４、ＢＩＯＳのフラッシュＲＯＭ９０５、そのＢＩＯＳフラッシュＲＯＭ９０５内のＢＩＯＳファームウェアプログラムコード９０６、そしてＢＭＣ９０７を有している。図９のＡの状態はサーバシステム９０１は電源がオフ状態であるため揮発性の記憶デバイスであるシステムのＲＡＭ９０４の内部は空の状態である。ＢＩＯＳフラッシュＲＯＭ９０５は不揮発性の記憶デバイスであるため、電源がオフの状態でも内部にＢＩＯＳファームウェアプログラムコード９０６を保持している。
【００４１】
図９のＢは図９のＡの状態からサーバシステム９０１の電源を入れた状態に遷移した状態を表す。電源をオンするとＢＩＯＳファームウェアプログラムコード９０６は全てのプログラムコードがシステムのＲＡＭ９０４の０ｘＥ００００番地にコピーされる、コピーされた後はＢＩＯＳファームウェアプログラムコードの処理が実行される時は全てこのシステムのＲＡＭ９０４上のコードが実行され、ＢＩＯＳフラッシュＲＯＭ９０５内のＢＩＯＳファームウェアプログラムコード９０６をシステム装置稼働中に読み書きなどのアクセスする事はない。この様にフラッシュＲＯＭ上のプログラムをＲＡＭにコピーしてその後はＲＡＭ上のプログラムで動作する仕組みをシャドウと呼び、ＩｎｔｅｌアーキテクチャのＩＡサーバやＩＢＭ  ＰＣ／ＡＴ互換機のパソコンでは一般的な公知技術である。この様にシャドウする事により、サーバシステム９０２が起動中にＢＩＯＳフラッシュＲＯＭ９０５に更新された新しいＢＩＯＳファームウェアプログラムコード９０６を書き込んだとしても、書き込んだ時点ではＢＩＯＳファームウェアプログラムコードはシステムのＲＡＭ９０４上の更新前のプログラムコードで動作しているため、新しいＢＩＯＳファームウェアプログラムコード９０６の動作にはならない。サーバシステム９０２を再起動すると、ふたたびＢＩＯＳファームウェアプログラムコード９０６がＢＩＯＳフラッシュＲＯＭ９０５からシステムのＲＡＭ９０４にシャドウされるため、その後は新しいＢＩＯＳファームウェアプログラムコード９０６の動作となる。このシャドウはＢＩＯＳだけではなくＢＭＣでも行なわれる。
【００４２】
次に図９のＣ、図９のＤを用いてＢＭＣファームウェアプログラムコードのシャドウに関して説明する。
【００４３】
図９のＣはサーバシステム９０８は電源オフの状態であり、図９のＡと図９のＣは全く同じ状態である。図９のＡではＢＭＣに関する説明ではないのでＢＭＣ９０７は小さく記載し、ＢＭＣ内部に関しては記載していないが図９のＣではＢＭＣ９０７を大きく記載し、ＢＭＣ９０７内部のＢＭＣのＣＰＵ９１０、ＢＭＣのＲＡＭ９１１、ＢＭＣのフラッシュＲＯＭ９１２、ＢＭＣのフラッシュＲＯＭ９１２内部のＢＭＣファームウェアプログラムコード９１３に関しても記載している。
【００４４】
図９のＤは図９のＣのサーバシステム９０８が電源オフの状態から遷移し、ＢＭＣに電源供給された状態である。通常ＡＣ電源を挿入しただけでＢＭＣに電源は供給される。ＢＭＣに電源供給されるとＢＭＣファームウェアプログラムコード９１３は全てのプログラムコードがＢＭＣのＲＡＭ９１１の固定番地にコピーされる、コピーされた後はＢＭＣファームウェアプログラムコードの処理が実行される時は全てこのＢＭＣのＲＡＭ９１１上のコードが実行され、ＢＭＣフラッシュＲＯＭ９１２内部のＢＭＣファームウェアプログラムコード９１３をシステム装置稼働中に読み書きなどのアクセスする事はない。この様にシャドウする事により、サーバシステム９０９が起動中にＢＭＣフラッシュＲＯＭ９１２に更新された新しいＢＭＣファームウェアプログラムコード９１３を書き込んだとしても、書き込んだ時点ではＢＭＣファームウェアプログラムコードはＢＭＣのＲＡＭ９１１上の更新前のプログラムコードで動作しているため、新しいＢＭＣファームウェアプログラムコード９１３の動作にはならない。ＢＭＣ９０７を再起動すると、ふたたびＢＭＣファームウェアプログラムコード９１３がＢＭＣフラッシュＲＯＭ９１２からＢＭＣのＲＡＭ９１１にシャドウされるため、その後は新しいＢＭＣファームウェアプログラムコード９１３の動作となる。
【００４５】
次に図１０を用いてＢＭＣファームウェア更新プログラムの動作を詳細に説明する。図１０の左上のサーバシステム９０９は先に説明の図９のＤの状態の図である。図９のＤではサーバシステム９０９のＨＤＤは記載していなかったが、本説明ではサーバシステム９０９のＨＤＤ１００１を追加で記載した。サーバシステム９０９の構成要素のうち、ＢＭＣファームウェア更新プログラムの動作説明で使用するＨＤＤ１００１、システムのＲＡＭ９０４、ＢＭＣのＲＡＭ９１１、ＢＭＣのフラッシュＲＯＭ９１２を拡大して図１０の下部に記載した。
【００４６】
ＨＤＤ１００１は内部にＢＭＣファームウェアイメージデータ１００２とＢＭＣファームウェア更新プログラム１００３を有している。例えばＢＭＣファームウェアのベンダーがＡＭＩ社であれば、ＢＭＣファームウェアイメージデータとはrom.imaという３２ＭＢまたは１６ＭＢのファイルとなり、ＢＭＣファームウェア更新プログラムはyafukcs.exeという実行ファイルとなる。これらがＨＤＤ１００１内の同じディレクトリに存在している状態である。
【００４７】
ステップＡ１はＢＭＣファームウェア更新プログラム１００３を実行した時の動作である、ＩｎｔｅｌアーキテクチャのＩＡサーバやパソコンではＨＤＤ上のプログラムはシステムのＲＡＭ９０４に読み込まれて実行される。ＢＭＣファームウェアイメージデータ１００２もシステムのＲＡＭ９０４に読み込まれる。
【００４８】
次にステップＡ２ではシステムのＲＡＭ上で動作しているＢＭＣファームウェア更新プログラムはＢＭＣファームウェアイメージデータ１００２をＢＭＣのＲＡＭ９１１の空き領域に転送する。ＢＭＣのＲＡＭの内部には先の図９のＣ、図９のＤにて説明した通りシャドウによってコピーされたＢＭＣファームウェアプログラムコードがありその構成要素の１つとしてアップデート実行部１００４を有している。ステップＡ２においてＢＭＣファームウェアイメージデータをシステムのＲＡＭ９０４からＢＭＣのＲＡＭ９１１に転送が終わると、ＢＭＣファームウェア更新プログラム１００３はＢＭＣのＲＡＭ９１１内のアップデート実行部１００４にアップデート実行コマンドを送る。この様にシステムのＲＡＭ９０４上のプログラムつまりホスト側のプログラムがＢＭＣのＲＡＭ９１１にデータを転送したり、あるいはＢＭＣのＲＡＭ上で動作するプログラムにコマンドを発行したりするインターフェースはIntel社、Hewlett-Packard社、NEC社、Dell社の４社で定めた共通仕様のインターフェースIntelligent Platform Management Interface Specificationに準拠しており、どのベンダーのＢＭＣを利用した場合もこの共通インターフェースは変わらない。
【００４９】
最後にステップＡ３としてＢＭＣファームウェアプログラムコード内のアップデート実行部１００４はＢＭＣのＲＡＭ９１１に既に転送されているＢＭＣファームウェアイメージデータをＢＭＣのフラッシュＲＯＭ９１２に書き込みを行なう。これによりファームウェアの更新が完了する。図９、図１０を用いたＢＭＣファームウェア更新プログラムの説明では仮想メディアに関しては利用しなかったが、この後の説明の為に図１０においてはＢＭＣファームウェアプログラムコードの１要素である仮想メディア１００５を記載しておく。
【００５０】
図５を用いた説明に戻ると、該当ファームウェアの更新が正常に終了した場合は該当するファームウェアのUP_REQUEST[xx]を０にクリアし、管理対象サーバ装置１０２を再起動する（ステップ５２）。もしこの段階でまだ更新要求があるファームウェアが残っている場合、すなわちUP_REQUEST[xx]が全て０でない場合は管理対象サーバ装置１０２再起動後の動作は図４のステップ４７と同様となり、ＢＩＯＳ１１１はＰＯＳＴにて再び仮想メディア１０９から強制起動(ブート)する。再度ステップ５２が実行され、このサイクルはUP_REQUEST[xx]が全て０になるまで繰り返される。
【００５１】
もしステップ５２にてUP_REQUEST[xx]が全て０にクリアされ更新要求があったファームウェアのアップデートが全て完了したら、システムの再起動要求を示すＢＭＣ１０７内のフラグRESTART_REQUESTをセットする（ステップ５３）。ＢＭＣ１０７内のリモートコンソールはRESTART_REQUESTを定期的に監視していてRESTART_REQUESTが１になった場合は仮想メディア１０９を切断し、FW_UPDATE_PROCESSのフラグを０にクリアしたのちに管理対象サーバ装置１０２を再起動する。この段階ではUP_REQUEST[xx]が全て０であるためＢＩＯＳ１１１のＰＯＳＴは停止することもなく、また仮想メディア１０９から強制ブートすることもなく、サーバユーザが設定したブートプライオリティの優先順位のデバイスから起動する。同時にアップデートマネージャーソフトウェア１０６もFW_UPDATE_PROCESSのフラグが０になった事を検知し、再び配信サーバ１００からのアップデート要求待ち状態となる（ステップ５４）。
【００５２】
次に図６を用いて本発明の第２の実施例を説明する。図１の実施例１とは、図１における管理端末１０１が図６においては他のサーバ装置１０３に置き換わった部分のみが異なる。
【００５３】
図１における管理端末１０１の上のアップデートマネージャーソフトウェア１０６は管理端末１０１のＨＤＤ１０５内に入っているシステムのＯＳであるＷｉｎｄｏｗｓやＬｉｎｕｘ上で動作している。つまりこのアップデートマネージャーソフトウェア１０６はＷｉｎｄｎｏｓ用とＬｉｎｕｘ用が存在する。第２の実施例ではこのうちＬｉｎｕｘ用のアップデートマネージャーソフトウェア１０６を使用する。図６の装置構成ではＢＭＣ１１２はサーバ装置１０３とは独立したプロセッサ、メモリリソースを使用して動くものであり、ＢＭＣ１１２のＯＳは一般的にはＬｉｎｕｘベースのものである。このため先に説明した図１において管理端末１０１のＨＤＤ１０５上のＬｉｎｕｘ上で動作するアップデートマネージャーソフトウェア１０６のＬｉｎｕｘ版と同じものが、図６におけるＢＭＣ１１２のＬｉｎｕｘ上で実行させることができる。
【００５４】
このＢＭＣのＬｉｎｕｘＯＳでＬｉｎｕｘ版のアップデートマネージャソフトウェアが動作する仕組みを図８と図１１を用いて説明する。
【００５５】
図８においてサーバ装置８０１とＬｉｎｕｘがＯＳとしてＨＤＤ内にインストールされた小型のパソコン８０２があると仮定する。サーバ装置８０１のマザーボード上にはＣＰＵとメモリとＨＤＤが存在する。また小型のパソコン８０２内部にもＣＰＵとメモリとＨＤＤが存在する。その小型のパソコン８０２をサーバ装置８０１の内部に入れた図がサーバ装置８０３である。そしてさらにそのサーバ装置８０３に入れたパソコンからディスプレイとキーボードなどユーザインターフェースは取り去り、また不揮発性の記憶エリアはＨＤＤではなくフラッシュＲＯＭに置き換えパソコンを１つの半導体チップ８０５のサイズまでさらに小型化した図がサーバ装置８０４である。１つの半導体チップ８０５でＬｉｎｕｘＯＳのパソコン相当の事ができるこの半導体チップ８０５をＢＭＣと呼んでいる。  つまりＢＭＣはサーバ装置の内部に、別のＬｉｎｕｘＯＳのパソコンが１台内蔵されており、それはサーバ装置のＣＰＵ、メモリ、ＨＤＤを使う事無く、ＢＭＣ自身のＣＰＵ、メモリ、ＲＯＭで独自に動作でき、パソコンで動くＬｉｎｕｘＯＳと同じものが動く為、広く提供されているＬｉｎｕｘのアプリケーションソフトウェアもＢＭＣのＬｉｎｕｘＯＳ上で使う事ができる。すなわち本発明によるアップデートマネージャーソフトウェア１０６もＬｉｎｕｘ版であればＢＭＣのＬｉｎｕｘＯＳ上で実行することができる。ただしアップデートマネージャーソフトウェア１０６をＢＭＣのＬｉｎｕｘＯＳ上で使う為の課題としてＣＰＵの差異がある。通常サーバ装置８０１やパソコン８０２のＣＰＵはＩｎｔｅｌ社製のものを採用している、しかしながらサーバ装置８０４内のＢＭＣ８０５のＣＰＵはアーム社製のものを採用しているものが多い、もしアップデートマネージャーソフトウェア１０６のＬｉｎｕｘ版はＩｎｔｅｌ社製のＣＰＵ上でコンパイルして作成されたものだとすると、アーム社製のＣＰＵ上では互換性の問題で実行できない。本問題を解決するための手段として、ＢＭＣファームウェアの開発環境、すなわちアーム社製のＣＰＵで動作するＬｉｎｕｘの開発環境にアップデートマネージャーソフトウェア１０６のソースコードを移し、ＢＭＣファームウェアの開発環境でアップデートマネージャーソフトウェア１０６のソースコードを再コンパイルすることで課題を解決できる。
【００５６】
図１１はアップデートマネージャーソフトウェア１１０３を内部にもったＢＭＣのＲＡＭ１１０１の図である。先に図９、図１０をもちいて説明したとおり、ＢＭＣファームウェアプログラムコードはＢＭＣのフラッシュＲＯＭからＢＭＣのＲＡＭにシャドウされる。先に説明の通りこのＢＭＣのＲＡＭにシャドウされたＢＭＣファームウェアプログラムコードの構成要素としてはアップデート実行部１１０５、仮想メディア１１０４を持っている。第２の実施例ではこれに加えてさらにアップデートマネージャーソフトウェア１１０３をこのＢＭＣファームウェアプログラムコードの構成要素として持つものである。第２の実施例で図１における管理端末１０１の代わりに図６におけるサーバ装置１０３を利用した場合サーバ装置１０３内部のＢＭＣ１１２のメモリの内部は図１１の様になるが、ＢＭＣファームウェアプログラムコードの構成要素である仮想メディア１１０４、アップデート実行部１１０５は利用しない。アップデートマネージャーソフトウェア１１０３のみが動作し、ＢＭＣのＲＡＭの空きエリアにアップデートツールイメージデータ１１０２を読み込む動作となる。
【００５７】
図１と図６を用いた説明に戻ると、図１の構成では管理端末１０１のＯＳシステムのＬＡＮが管理対象サーバ装置１０２のＢＭＣ１０７の管理ＬＡＮ１０８と同一ネットワークに接続されている。同様に図６では管理対象サーバ装置１０２のＢＭＣ１０７の管理ＬＡＮ１０８と他のサーバ装置１０３のＢＭＣの管理ＬＡＮが同一ネットワークに接続されている。従って図１も図６も装置構成、ネットワーク構成、使用するアップデートマネジャーソフトウェア１０６の機能および動作は全く同じとなる。従って図６の第２の実施例に関しての動作フローは、前記にて図２、図３、図４、図５を用いて説明した第１の実施例の手順と全く同じフローをそのまま用いることができる。
【００５８】
最後に、仮想メディアを利用して動作するアップデートツールイメージデータに関して説明する。
【００５９】
まず図１を用いてＢＭＣの仮想メディア機能に関して説明する。管理対象サーバ装置１０２のＢＭＣ１０７は管理端末１０１に存在しているＣＤ／ＤＶＤドライブを管理対象サーバ装置１０２に接続されているＣＤ／ＤＶＤドライブであるかの様に管理対象サーバ装置１０２のＢＩＯＳやＯＳに対して見せかけることができる。これが仮想メディア機能である。この機能を用いると管理端末１０１のＣＤ／ＤＶＤドライブに起動可能なＣＤ／ＤＶＤメディアを入れておけば、管理対象サーバ装置１０２で起動ＯＳとして起動させることができる。また実際にＣＤ／ＤＶＤを入れておかなくてもＣＤ／ＤＶＤをＩＳＯイメージ化したデータファイルをＣＤ／ＤＶＤメディアの代用として使用する事が可能である。本発明ではこの仮想メディア機能を使用してＩＳＯイメージデータを用いて管理対象サーバ装置１０２を起動する方法を使用する。
【００６０】
次に図７を用いてアップデートツールイメージデータ１０４に関して説明する。アップデートツールイメージデータ１０４はＩＳＯイメージファイルであり、データの元となるのは実存するＣＤ／ＤＶＤのソフトウェアメディアである。このソフトウェアメディアはＭＳ−ＤＯＳなど自己起動可能なＯＳ部分７００、この自己起動可能なＯＳによって起動後、ＩＰＭＩのＫＣＳコマンドを使用して管理対象サーバ装置のＢＭＣにコマンドを発行し、ＢＭＣ内部のフラグを設定／参照するアップデート管理部分７０１、そしてファームウェア更新プログラム部分７０２、またそのファームウェア更新プログラム部分７０２の各更新プログラムから読み込まれるファームウェアイメージデータ部分７０３から成る。ファームウェア更新プログラム部分７０２には図７に示す通り、更新対象とするファームウェア更新プログラムが複数種類入っている事を想定している。またこれらのファームウェア更新プログラムは各ファームウェアベンダーから提供されたものを想定している。
【００６１】
まずＯＳ部分７００から自己起動し、その後、アップデート管理部分７０１がＢＭＣ内部のフラグを参照する、アップデート管理部分７０１の動作の詳細は前記の図５を用いて説明したステップ５２、ステップ５３の通りである。例えばUP_REQUEST[xx]の、ＢＭＣファームウェア用のフラグはUP_REQUEST[00]、ＢＩＯＳ用のフラグはUP_REQUEST[01]、ＲＡＩＤ用のファームウェアはUP_REQUEST[02]であったとすると、まずはもしUP_REQUEST[00]が１にセットされていれば、図７のファームウェア更新プログラム部分７０２のＢＭＣファームウェア更新プログラムが実行され、実行が正常終了すると、UP_REQUEST[00]を０にクリアし、システムを再起動する。次に再起動後、UP_REQUEST[01]が１にセットされていれば、図７のファームウェア更新プログラム部分７０２のＢＩＯＳファームウェア更新プログラムが実行され、実行が正常終了すると、UP_REQUEST[01]を０にクリアし、システムを再起動する。そして次に再起動後、UP_REQUEST[02]が１にセットされていれば、図７のファームウェア更新プログラム部分７０２のＲＡＩＤファームウェア更新プログラムが実行され、実行が正常終了すると、UP_REQUEST[02]を０にクリアし、システムを再起動するという順で動作する。
【００６２】
この様な動作が可能なＣＤ／ＤＶＤメディア７０４をまず作成する。そして図７の通りそのＣＤ／ＤＶＤメディアをＩＳＯイメージ化したものが、図１の配信サーバ１００内部にあるアップデートツールイメージデータ１０４である。
【符号の説明】
【００６３】
１００  配信サーバ
１０１  管理端末
１０２  管理対象サーバ装置
１０３  他のサーバ装置
１０４  アップデートツールイメージデータ
１０５  ＨＤＤ
１０６  アップデートマネージャーソフトウェア
１０７  ＢＭＣ
１０８  管理ＬＡＮ
１０９  仮想メディア
１１０  ファームウェア（Ｆ／Ｗ）
１１１  ＢＩＯＳ
１１２  ＢＭＣ
７００  ＯＳ部分
７０１  アップデート管理部分
７０２  ファームウェア更新プログラム部分
７０３  ファームウェアイメージデータ部分
７０４  ＣＤ／ＤＶＤメディア
８０１  サーバ装置
８０２  小型パソコン
８０３  サーバ装置にパソコンを内蔵したもの
８０４  サーバ装置のパソコンを小型の半導体チップ化したもの
９０１  電源オフの状態のサーバシステム
９０２  電源オンの状態のサーバシステム
９０３  システムのＣＰＵ
９０３  システムのＲＡＭ
９０５  ＢＩＯＳフラッシュＲＯＭ
９０６  ＢＩＯＳファームウェアプログラムコード
９０７  ＢＭＣ
９０８  電源オフの状態のサーバシステム
９０９  電源オンの状態のサーバシステム
９１０  ＢＭＣ内部のＣＰＵ
９１１  ＢＭＣ内部のＲＡＭ
９１２  ＢＭＣのフラッシュＲＯＭ
９１３  ＢＭＣファームウェアプログラムコード
１００１  サーバシステムのＨＤＤ
１００２  ＢＭＣファームウェアイメージデータ
１００３  ＢＭＣファームウェア更新プログラム
１００４  アップデート実行部
１００５  仮想メディア
１１０１  ＢＭＣのＲＡＭの構成図
１１０２  アップデートツールイメージデータ
１１０３  アップデートマネージャーソフトウェア
１１０４  仮想メディア
１１０５  アップデート実行部
【図１】
2015060411.tif 000004
【図２】
2015060411.tif 000005
【図３】
2015060411.tif 000006
【図４】
2015060411.tif 000007
【図５】
2015060411.tif 000008
【図６】
2015060411.tif 000009
【図７】
2015060411.tif 000010
【図８】
2015060411.tif 000011
【図９】
2015060411.tif 000012
【図１０】
2015060411.tif 000013
【図１１】
2015060411.tif 000014