JP2016110372A - 情報処理装置、更新時間推定プログラム、及び更新時間推定方法 - Google Patents

Abstract

【課題】ソフトウェアの更新処理が行なわれるモジュールを複数含む対象装置について、更新時間を容易に推定する。【解決手段】ソフトウェアの更新処理が行なわれるモジュールを複数含む対象装置１ａに対応した、前記複数のモジュールに係る複数の更新処理の実行順序を示す情報２２に基づき、前記複数の更新処理から、並行して実行される複数の更新処理を一処理ブロックとした一以上の第１処理ブロックを特定する特定部２５と、前記複数の更新処理の各々にかかる更新時間を示す情報３２を用いて、前記特定部２５が特定した第１処理ブロックごとの更新時間を推定する第１推定部２６，２７と、更新時間を示す情報３２及び前記第１推定部２６，２７が推定した第１処理ブロックごとの更新時間の少なくとも一方に基づいて、前記対象装置１ａの更新時間を推定する第２推定部２８と、をそなえる。【選択図】図６

Description

本発明は、情報処理装置、更新時間推定プログラム、及び更新時間推定方法に関する。

サーバ、ストレージ、及びネットワーク機器等を含むシステムでは、システム内の一部の装置のファームウェアについてアップデート（以下、ファームアップともいう）が行なわれることがある。

このようなシステムでは、一部の装置がファームアップされる間、他の装置への影響を考慮して関連するシステムの運用が停止される。このため、ファームアップの作業者は、一部の装置のファームアップが可能な時間帯をシステムの運用スケジュールに照らし合わせて決定し、ファームアップのスケジュールを決定することになる。

ところで、複数の装置を組み合わせた複合システムがファームアップ対象の装置（対象装置）となる場合がある。複合システムとしては、例えば複数の装置（部品）を含み、部品単位で製品化されている部品を組み合わせて、別の固有な機能を持った製品形態を構成した装置が挙げられる。また、複合システムとして、例えばＣＰＵ（Central Processing Unit）やメモリ等を含む複数のモジュールをそなえ、各モジュールに装置全体を制御するための機能を分割配置し、各モジュールの機能をファームウェアによって制御する形態の装置も挙げられる。

以下、このような複合システムとして、仮想テープライブラリ装置を例に挙げて説明する。仮想テープライブラリ装置は、例えば制御装置、ＲＡＩＤ（Redundant Arrays of Inexpensive Disks）装置、ＬＡＮ（Local Area Network）ハブ、ＦＣ（Fibre Channel）スイッチ、電源制御装置、テープライブラリ装置等の部品を搭載することができる。

仮想テープライブラリ装置は、図３３に例示するように、複数のモデル及びオプション構成が存在し、これらの構成別に、構成部品のタイプや搭載台数等が異なる。図３３の例では、モデルＡの基本構成は、制御装置、ＲＡＩＤ装置、ＬＡＮハブ、ＦＣスイッチ、電源制御装置、テープライブラリ装置Ａであり、モデルＢの基本構成は、モデルＡの基本構成に対して、ＦＣスイッチを無くしテープライブラリ装置Ａとは製品仕様が異なるテープライブラリ装置Ｂにしたものである。また、モデルＣの基本構成は、モデルＡの基本構成に対して、テープライブラリ装置Ａとは製品仕様が異なるテープライブラリ装置Ｃにしたものであり、モデルＣのオプション構成であるマルチＬＩＢ（Library）構成は、モデルＣの基本構成に対して、テープライブラリ装置Ｃを２台設けたものである。

仮想テープライブラリ装置のファームアップでは、各部品の更新ファームウェアをまとめた更新ファームセットが提供され、作業者は、各部品をそれぞれ指定されたファーム版数に更新する作業を行なう。更新の手順は、仮想テープライブラリ装置の構成により予めモデル単位（装置構成単位）で定義された更新手順（以下、アップデートフローという）に基づいて実施される。

図３４は、モデル別に定義されたアップデートフローと総ファームアップ推定時間との関係を例示する図である。図３４に示すように、モデルＡ〜モデルＣの各々は、それぞれの搭載する部品が異なり、互いに異なるアップデートフローとなるため、総ファームアップにかかる推定時間も互いに異なるものとなる。なお、図３４に示すアップデートフローは、説明のためモデルごとの差異を明確に示したものであり、図３３に示すモデルＡ〜Ｃの実際のアップデートフローとは異なる。

仮想テープライブラリ装置のファームアップでは、図３４に例示するアップデートフロー（手順書）に従って、作業者がそれぞれの部品のファームアップを個々に行なうことになる。

次に、図３５を参照して作業者が複合システムのファームアップを行なう手順の一例を説明する。

まず、作業者は、ファームアップ対象のモデルを判別し、対応するアップデートフローを入手して（ステップＳ１０１）、アップデートフローに従い、ファームアップする部品を選択する（ステップＳ１０２）。そして、作業者は、選択した部品の版数が変更されているか否かを判断する（ステップＳ１０３）。

選択した部品の版数が変更されている場合（ステップＳ１０３のＹｅｓルート）、作業者は、更新ファームセットから対象部品のファームウェアを取り出し、対象部品をファームアップして（ステップＳ１０４）、処理がステップＳ１０５に移行する。選択した部品の版数が変更されていない場合も（ステップＳ１０３のＮｏルート）、処理がステップＳ１０５に移行する。

ステップＳ１０５では、作業者が、構成部品で他に並行してファームアップ可能な部品があるか否かを判断し、ある場合には（ステップＳ１０５のＹｅｓルート）、処理がステップＳ１０３に移行する。一方、他に並行してファームアップ可能な部品がない場合には（ステップＳ１０５のＮｏルート）、作業者は、部品ごとにファームアップの完了を待ち受ける（ステップＳ１０６，Ｓ１０６のＮｏルート）。

ファームアップが完了した部品がある場合（ステップＳ１０６のＹｅｓルート）、作業者は、構成部品でファームアップが可能となった部品があるか否かを判断し（ステップＳ１０７）、ある場合には（ステップＳ１０７のＹｅｓルート）、処理がステップＳ１０３に移行する。一方、構成部品でファームアップが可能となった部品がない場合（ステップＳ１０７のＮｏルート）、作業者は、全ての構成部品のアップデートが完了したか否かを判断する（ステップＳ１０８）。完了していない場合（ステップＳ１０８のＮｏルート）、処理がステップＳ１０６に移行する。

全ての構成部品のアップデートが完了した場合（ステップＳ１０８のＹｅｓルート）、処理が終了する。

なお、ファームウェアの更新時間を算出する手法としては、種々の技術が知られている（例えば、下記特許文献１及び２参照）。

特開２００７−３３４６３６号公報 特開２００３−０５８３３５号公報 特開２００８−１５２４８２号公報 特開２０１２−０４３１８７号公報

しかしながら、仮想テープライブラリ装置等の複合システムの総ファームアップ推定時間は、図３４に例示するように、定義されたアップデートフロー（更新手順）、並びに、個々の部品についてのファームアップの有無及び推定時間等によって異なる。

全体のシステムにおいて複合システムが活性状態の場合、当該複合システムのファームアップを行なうことは困難であり、この場合、当該複合システムのファームアップは、システムから切り離してから実施されることになる。

このため、ファームアップの対象装置を使用している部門等で予め対象装置をファームアップするためのシステム運用スケジュールを立案することが好ましい。

しかし、上述のように、対象装置としての複合システムのファームアップは、複数の部品等のモジュールがアップデートフローに従って処理される。従って、対象装置全体をファームアップするのにかかる総ファームアップ推定時間を容易に求めることは難しい。

１つの側面では、本発明は、ソフトウェアの更新処理が行なわれるモジュールを複数含む対象装置について、更新時間を容易に推定することを目的とする。

１つの態様では、本件の情報処理装置は、特定部と、第１推定部と、第２推定部とをそなえる。前記特定部は、ソフトウェアの更新処理が行なわれるモジュールを複数含む対象装置に対応した、前記複数のモジュールに係る複数の更新処理の実行順序を示す情報に基づき、前記複数の更新処理から、並行して実行される複数の更新処理を一処理ブロックとした一以上の第１処理ブロックを特定する。前記第１推定部は、前記複数の更新処理の各々にかかる更新時間を示す情報を用いて、前記特定部が特定した第１処理ブロックごとの更新時間を推定する。前記第２推定部は、更新時間を示す情報及び前記第１推定部が推定した第１処理ブロックごとの更新時間の少なくとも一方に基づいて、前記対象装置の更新時間を推定する。

１つの側面では、ソフトウェアの更新処理が行なわれるモジュールを複数含む対象装置について、更新時間を容易に推定することができる。

複合システムのアップデートフローの一例を示す図である。 複合システムの部品ごとのファームアップ時間の一例を示す図である。 図２に示すファームアップ時間を図１に示すアップデートフローに適用した場合の更新時間の最長ルートの一例を示す図である。 一実施形態に係るシステムの構成例を示す図である。 一実施形態に係るシステムの詳細な構成例を示す図である。 一実施形態に係る運用コンソールの構成例を示す図である。 アップデートフローデータベースのフローテーブルの一例を示す図である。 メインルートの一例を説明する図である。 分岐ルートの一例を説明する図である。 アップデートフローデータベースの要素管理テーブルの一例を示す図である。 図１０に示す要素管理テーブルに部品ファームアップ処理を追加した場合の一例を示す図である。 分岐ポイントの一例を説明する図である。 合流ポイントの一例を説明する図である。 アップデートフローデータベースに基づくファームアップ手順の作成手法の一例を示す図である。 一実施形態に係るシステムの他の構成例を示す図である。 一実施形態に係るブロック分割部による処理ブロックの分割処理の一例を説明する図である。 一実施形態に係るブロック分割部による処理ブロックの分割処理の一例を説明する図である。 一実施形態に係るブロック分割部によるブロックルートの特定処理の一例を説明する図である。 一実施形態に係るブロック分割部によるブロックルートの特定処理の一例を説明する図である。 ファームアップ時間データベースの一例を示す図である。 一実施形態に係るファームアップ時間推定部による更新時間推定処理の一例を説明するフローチャートである。 一実施形態に係るＤＢ選択部によるＤＢ選択処理の一例を説明するフローチャートである。 一実施形態に係るブロック分割部によるブロック分割処理の一例を説明するフローチャートである。 一実施形態に係る推定時間選択部によるファームアップ時間選択処理の一例を説明するフローチャートである。 一実施形態に係る第１算出部によるブロック推定時間算出処理の一例を説明するフローチャートである。 実施例に係る複合システムのアップデートフローを示す図である。 実施例に係るファームアップ時間データベースを示す図である。 第１実施例に係るアップデートフローデータベースのフローテーブルを示す図である。 第１実施例に係る総ファームアップ推定時間の算出結果を示す図である。 第２実施例に係るアップデートフローデータベースのフローテーブルを示す図である。 第２実施例に係る総ファームアップ推定時間の算出結果を示す図である。 一実施形態に係る運用コンソールのハードウェア構成例を示す図である。 仮想テープライブラリ装置のモデル及びオプションごとの構成例を示す図である。 モデル別に定義されたアップデートフローと総ファームアップ推定時間との関係を例示する図である。 複合システムのファームアップを行なう手順の一例を説明するフローチャートである。

以下、図面を参照して本発明の実施の形態を説明する。ただし、以下に説明する実施形態は、あくまでも例示であり、以下に明示しない種々の変形や技術の適用を排除する意図はない。すなわち、本実施形態を、その趣旨を逸脱しない範囲で種々変形して実施することができる。なお、以下の実施形態で用いる図面において、同一符号を付した部分は、特に断らない限り、同一若しくは同様の部分を表す。

〔１〕複合システムの総ファームアップ推定時間について
はじめに、図１〜図３を参照しながら、複合システムの総ファームアップ推定時間について説明する。

以下、複合システムが部品１〜部品９の９個の部品を含み、図１に例示するアップデートフローが定義されているものとして説明する。

複合システムのファームアップを行なう際、作業者は、図１に示すファームアップ処理を机上でシミュレートし、以下のような手順でファームアップの対象装置全体の推定時間を求めることが考えられる。

（ｉ） 複合システムに適用されているファームウェアの版数情報から部品ごとのファーム更新の有無を調べる。
（ii） 使用するアップデートフローにそれぞれの部品のファームアップ時間を代入する。
（iii） アップデートフローに従い、ファームアップ対象の装置全体のファームアップにかかる時間を算出する。

ここで、図１のアップデートフローにおいて、ポイント１及びポイント３は、処理が分岐して複数の部品が並行にファームアップされることを表す分岐ポイントを示す。また、ポイント２及びポイント４は、複数に分かれた分岐ルートが合流することを表す合流ポイントを示す。合流ポイントでは、対応する分岐ポイントで分岐された全てのルートの処理が完了したときに、先の処理に進むことができるものとする。

複合システムの部品ごとのファームアップ時間の一例を図２に示す。図２のファームアップ時間を図１に示すアップデートフローに適用すると、図３に例示するように、矢印で示すルート（部品１，部品２，部品３，部品６，部品９）が最も時間のかかるルートであることが判明し、この時間が複合システムの総ファームアップ推定時間となる。

具体的には、図３の例において、ポイント１からポイント２の分岐ルートでは、部品３＋部品６のファームアップを行なう時間が残りの２ルート（部品４＋部品７，部品５）よりも長い。従って、ポイント２では、残りの２ルートは、部品３＋部品６のルートの完了を待ち合わせることになる。

また、ポイント３からポイント４の分岐ルートでは、部品９のファームアップを行なう時間が部品８のファームアップを行なう時間よりも長く、部品８のルートは、部品９のルートの完了を待ち合わせることになる。

よって、図３の例では、図１に示すアップデートフローを用いた複合システムの総ファームアップ推定時間は、部品１（２０分）＋部品２（１０分）＋部品３（８０分）＋部品６（４０分）＋部品９（６０分）＝総ファームアップ推定時間（２１０分）となる。

以上のように、複合システムのファームアップにかかる更新時間は、作業者により机上で推定（算出）される。従って、複合システムの規模に従って、更新時間の計算が煩雑となり、作業者は、更新時間を容易に求めることが困難となる。

〔２〕一実施形態
そこで、一実施形態に係るシステムでは、以下に詳述する手法により、ソフトウェアの更新処理が行なわれるモジュールを複数含む対象装置について、更新時間を容易に推定することを可能とする。

〔２−１〕システムの構成例
以下、図４及び図５を参照して、一実施形態に係るシステムの構成例について説明する。一実施形態に係るシステムは、図４に例示するように、対象装置１及び対象装置１を管理する情報処理装置２をそなえる。

対象装置１は、構成部品として、複数（図４の例ではｍ個；ｍは自然数）のモジュール１００−１〜１００−ｍをそなえる。以下、モジュール１００−１〜１００−ｍを区別しない場合には単にモジュール１００という。対象装置１としては、例えば複合システムが挙げられる。

情報処理装置２は、例えば対象装置１のベンダ等の開発元から提供される更新ファームセット３０を入力され、対応する対象装置１に対する更新ファームセット３０の適用（複数のモジュール１００の各々のファームウェアの更新）を管理する。この管理には、例えば対象装置１に対する更新ファームセット３０を用いたファームアップの更新時間の推定処理が含まれる。また、この管理には、対象装置１に対する更新ファームセット３０の適用（更新）処理が含まれてもよい。

次に、システムの詳細な構成例を説明する。図５に例示するように、システムは、仮想テープライブラリ装置１ａ、運用コンソール２ａ、及びホストサーバ３をそなえる。

仮想テープライブラリ装置１ａは、ホストサーバ３に対して、仮想テープライブラリを提供する装置であり、制御システム４と、１以上（図５の例では２つ）のテープライブラリ装置９ａ及び９ｂとをそなえる。

テープライブラリ装置９ａ及び９ｂは、データを記憶する媒体カートリッジの一例としてのテープカートリッジを複数収納し、ホストサーバ３からのアクセス要求に応じてテープカートリッジに対するアクセスを行なう。テープライブラリ装置９ａ及び９ｂは、それぞれ、テープカートリッジに対するデータの記録及び再生等を行なう複数のドライブ９１と、媒体カートリッジのピックアップ、搬送、ドライブ９１への挿入等を行なうロボット９２とをそなえる。

制御システム４は、制御装置５ａ〜５ｄ，７ａ〜７ｄ，１１ａ及び１１ｂ、ＦＣスイッチ６ａ及び６ｂ、ＲＡＩＤ装置８、ＬＡＮハブ１０ａ及び１０ｂ、ライブラリ制御装置１２ａ及び１２ｂ、並びに電源制御装置１３ａ及び１３ｂをそなえる。

制御装置５ａ〜５ｄは、ホストサーバ３と物理層（ＰＨＹ）を介して複数のホストＩ／Ｆ（Interface）バスで接続され、ホストサーバ３との間のアクセス制御を行なう。制御装置７ａ〜７ｄは、ドライブ９１とＦＣで接続され、ドライブ９１との間のアクセス制御を行なう。なお、制御装置５ａ〜５ｄはチャネルアダプタ（ＣＡ；Channel Adaptor）の一例であり、制御装置６ａ〜６ｄはデバイスアダプタ（ＤＡ；Device Adaptor）の一例である。

ＦＣスイッチ６ａ及び６ｂは、ＦＣを介して接続された制御装置５ａ〜５ｄと制御装置７ａ〜７ｄとの間におけるデータ転送（切り替え）を行なう。ＲＡＩＤ装置８は、ＦＣスイッチ６ａ及び６ｂとＦＣを介して接続され、ホストサーバ３とテープライブラリ装置９ａ又は９ｂとの間のアクセスに係るデータ（リード／ライトデータ）を一時的に記憶する。ＲＡＩＤ装置８は、仮想テープライブラリ装置１ａにおけるキャッシュの役割を持つ。なお、ＲＡＩＤ装置８は、ＨＤＤ（Hard Disk Drive）等の磁気ディスク装置及びＳＳＤ（Solid State Drive）等の半導体ドライブ装置の少なくとも１つを含んでよい。或いは、ＲＡＩＤ装置８は階層管理の一次ストレージとして用いられてもよい。この場合、ＲＡＩＤ装置８は仮想テープライブラリ装置１ａとして動作して高速アクセスを可能にし、アンロード指示でＲＡＩＤ装置８のデータが二次ストレージとしてのテープライブラリ装置９ａ及び９ｂのテープに書き込まれる。

ＬＡＮハブ１０ａ及び１０ｂは、運用コンソール２ａ、制御装置５ａ〜５ｄ、７ａ〜７ｄ、１１ａ及び１１ｂ、ライブラリ制御装置１２ａ及び１２ｂ、並びに電源制御装置１３ａ及び１３ｂと内部制御バスを介して接続され、これらの装置間における制御信号の転送を行なう。

制御装置１１ａ及び１１ｂは、ＬＡＮハブ１０ａ及び１０ｂを介して、制御システム４内の各装置の設定や情報の取得等の各種制御を行なう。なお、ホストサーバ３又は運用コンソール２ａから制御装置１１ａ及び１１ｂまでの間は制御バスで接続され、制御装置１１ａ及び１１ｂは、ホストサーバ３又は運用コンソール２ａとの間で通信を行なう。

ライブラリ制御装置１２ａ及び１２ｂは、ロボット９２の駆動制御等を行なう。電源制御装置１３ａ及び１３ｂは、図示しない電源装置に接続された各装置について、電源のＯＮ／ＯＦＦ制御を行なう。

上述した装置５ａ〜５ｄ、６ａ及び６ｂ，７ａ〜７ｄ，８，９ａ及び９ｂ，１０ａ及び１０ｂ，１１ａ及び１１ｂ，１２ａ及び１２ｂ，並びに１３ａ及び１３ｂの各々は、ファームウェア（ソフトウェア）によってその機能の少なくとも一部が制御される。また、上記装置の各ファームウェアは、図４に例示する更新ファームセット３０に含まれる複数の更新ファームウェアによって更新され得る。換言すれば、仮想テープライブラリ装置１ａは、上記装置の各々のファームウェアを更新するファームアップ機能をそなえているといえる。

このように、上記装置の各々は、図４に例示するモジュール１００と同様のモジュール１００ａであるといえる。また、仮想テープライブラリ装置１ａは、複数のモジュール１００ａを含む複合システム（対象装置１）の一例である。

運用コンソール２ａは、仮想テープライブラリ装置１ａのインタフェース（ＬＡＮハブ１０ａ及び１０ｂ）を介して仮想テープライブラリ装置１ａの管理（制御）を行なう管理サーバの一例である。例えば運用コンソール２ａは、仮想テープライブラリ装置１ａのファームアップの際に、仮想テープライブラリ装置１ａの更新ファームセット３０を読み込み、以下に詳述する総ファームアップ推定時間の算出や、ファームアップ処理等を行なうことができる。

ホストサーバ３は、仮想テープライブラリ装置１ａに対するアクセスを行なうサーバであり、例えば仮想テープライブラリ装置１ａの利用者等により用いられる。

運用コンソール２ａ及びホストサーバ３としては、それぞれ、例えばＰＣやサーバ等のコンピュータ（情報処理装置）が挙げられる。

〔２−２〕運用コンソールの構成例
次に、図６を参照して、一実施形態に係る運用コンソール２ａの構成例を説明する。運用コンソール２ａは、仮想テープライブラリ装置１ａとＬＡＮ等により接続される。また、運用コンソール２ａは、更新ファームセット３０を入力される。

更新ファームセット３０は、複数のファームウェアデータ３１と、ファームアップ時間データベース３２とを含む。複数のファームウェアデータ３１は、対象装置１としての仮想テープライブラリ装置１ａに含まれる複数のモジュール１００ａに適用する更新用のファームウェアである。なお、ファームアップ時間データベース３２の説明は後述する。

運用コンソール２ａは、更新ファームセット３０を入力（提供）されると、複数のファームウェアデータ３１とファームアップ時間データベース３２とを記憶装置、例えば保持部２１に保持してよい。

運用コンソール２ａは、図６に例示するように、保持部２１及びファームアップ時間推定部２３をそなえる。なお、運用コンソール２ａは、ファームウェア更新処理部２９をそなえてもよい。

保持部２１は、データを記憶する記憶装置の一例であり、図６に例示するように、アップデートフローデータベース２２を保持する。アップデートフローデータベース２２には、運用コンソール２ａが管理する全ての複合システムについて、複合システムごとに、構成部品と構成部品の更新順序（ファームウェアの更新処理の実行順序）とを定義した情報が含まれる。また、アップデートフローデータベース２２には、更新ファームセット３０に含まれる、構成部品のファームアップにかかる時間の情報が設定され得る。

アップデートフローデータベース２２は、システム又は仮想テープライブラリ装置１ａの運用開始又は構成変更の発生等の所定のタイミングで、システム又は仮想テープライブラリ装置１ａの管理者等により予め作成され、保持部２１に設定される。

〔２−２−１〕アップデートフローデータベースの説明
以下、アップデートフローデータベース２２について説明する。なお、便宜上、以下の説明では、仮想テープライブラリ装置１ａが部品１〜部品９の９個の構成部品（モジュール１００ａ）を含み、図１に例示するアップデートフローによりファームアップが行なわれるものとする。

図７は、アップデートフローデータベース２２のフローテーブルの一例を示す図である。図７に例示するように、アップデートフローデータベース２２は、図１に例示するアップデートフロー（手順書）を、総ファームアップ推定時間の自動算出を行なうためにデータベースとして定義したものであり、複数（図７の例では４つ）のフローテーブルを含む。

フローテーブルは、各々が１つのルートを示し、各ルートは、処理要素としての“部品ファームアップ処理（UP_UNIT_xxx）”、“分岐ポイント（Branch_xx）”、“合流ポイント（Join_xx）”の少なくとも１つを含むリスト構造体の集合である。

フローテーブルのうちの１つは、アップデートフローのメインルート（図７の例ではRoute_001）を表し、メインルート以外のフローテーブルは、メインルートから分岐した分岐ルート（図７の例ではRoute_002〜Route_004）を表す。

ルート（Route_xxx）は、リスト構造をしており、リストの順番に処理が行なわれる流れを示している。複数部品を並行して（同時に）ファームアップすることを定義するには、１つのルートではなく、並行して行なわれる部品の数のルートが用いられる。このため、複数部品を並行してファームアップするには、予め分岐ポイント（Branch_xx）により複数の分岐ルート（Route_xxx）を作成することになる。

仮想テープライブラリ装置１ａのファームアップが開始されると、図８に例示するように、メインルート（Route_001）が最初に処理され、部品ファームアップ処理、分岐ルートの生成、分岐ルートの合流等が行なわれる。分岐ルートにおいても、図９に例示するように、親ルート（メインルート又は分岐元の分岐ルート）の処理と並行して、部品ファームアップ処理、更なる分岐ルートの生成、別の分岐ルートからの合流等が行なわれる。分岐ルートは最終的にメインルートに合流するため、メインルートが終了した時点で、仮想テープライブラリ装置１ａの全ての部品のファームアップ処理が完了する。

部品ファームアップ処理（UP_UNIT_xxx）は、各部品のファームアップを行なう処理を示すポイント（処理要素）である。UP_UNIT_xxxに対応する部品は、図１０に例示するように、アップデートフローデータベース２２に含まれる要素管理テーブルで対応付けられる。一例として、図１０に示すように、UP_UNIT_001には部品１のファームアップ処理が対応付けられる。

図１０に例示するように、部品ファームアップ処理（UP_UNIT_xxx）は、仮想テープライブラリ装置１ａの全ての部品１〜９を一意に特定することができる情報である。仮想テープライブラリ装置１ａの構成部品が新型モデルの追加等により追加又は変更があった場合、図１１に例示するように、新たな構成部品を要素管理テーブルに追加することができる（部品１０及び部品１１参照）。

分岐ポイント（Branch_xx）は、ルートが分岐するポイント（処理要素）、つまりファームアップの並行実施が可能となるポイントである。Branch_xxでは、１以上のルート（Route_xxx）が新たに生成され、ルートの数だけ並行して部品のファームアップが可能となる。なお、図７のRoute_001に示すように、Branch_xxに続けて付された括弧（）内の１以上のRoute_xxxは、Branch_xxによって作成されるルートを示す。

図１２に例示するように、データベース定義されたアップデートフローでは、ファームアップの開始時に、メインルート（Route_001）のフローが作成される。Route_001のフローに分岐ポイント（Branch_xx）が定義されると、分岐ポイント（Branch_xx）が示す新規ルート（Route_xxx）が生成され、部品ファームアップ処理は分岐したルートの分だけ複数並行して実施可能となる。

合流ポイント（Join_xx）は、ルートが合流するポイント（処理要素）、つまりファームアップの並行実施が終了するポイントである。Join_xxでは、２以上のルートが合流し、１つのルートとしての処理の流れに戻る。なお、図７に示すように、Join_xxに続けて付された括弧（）内がBaseの場合（Route_001参照）、当該Join_xxを含むルートが合流される合流ポイントであることを示す。一方、Join_xxに続けて付された括弧（）内がBaseではなくRoute_xxxの場合（Route_002〜Route_004参照）、当該Join_xxを含むルートが括弧（）内のRoute_xxxで指定されたルートに合流し、当該Join_xxを含むルートが終了（消滅）することを示す。

図１３に例示するように、分岐したルートは合流ポイント（Join_xx）で合流し、再若番の分岐ルートを除き、その他の分岐ルートは終了する。図１３の例では、Join_01でRoute_001とRoute_002とが合流する場合、Route_002の分岐ルートは終了し、Route_001の分岐ルート（メインルート）は継続する。なお、Route_001は常に合流されるルートであるため、Route_001は、アップデートフローの終了を以て終了する。

このように、アップデートフローデータベース２２（フローテーブル）は、メインとなるルート（Route_001）で始まり、部品が並行して処理可能な場合は分岐ポイント（Branch_xx）で新たな分岐ルート（Route_xxx）が作成される。各ルート上では、部品のファームアップ処理（UP_UNIT_xxx）が手順に沿って設定され、仮想テープライブラリ装置１ａのファームアップの手順が示される。分岐ルートは、合流ポイント（Join_xx）で指定されたルートに合流して、最終的に１つのルート（メインルート）に集約される。

なお、現在考えられる複合システムでは多種多様に亘る構成部品が存在するわけではないため、データベース定義されたフローテーブルに存在するルートの数（リスト構造体の数）、及び各ルートに登録される処理要素数の上限は特に定義しなくてもよい。

以上のように、メインルートには、ファームアップを直列（シーケンシャル）に実行する（並行して実行しない）構成部品同士の実行順序と、並行して実行できる構成部品の実行順序を定義する分岐ルートへの分岐ポイントと、分岐ルートからの合流ポイントと、が定義されるといえる。また、分岐ルートには、分岐ルートにおける構成部品のファームアップの実行順序と、どのルートのどの合流ポイントに合流するかを示す情報と、が定義されるといえる。

上述したアップデートフローデータベース２２（フローテーブル及び要素管理テーブル）は、図１に示すアップデートフローをデータベース定義したものであるため、アップデートフローデータベース２２からアップデートフローを復元することも可能である。以下、アップデートフローに基づき定義されたアップデートフローデータベース２２が可逆性を有することを説明するため、図１４を参照して、運用コンソール２ａによるアップデートフローデータベース２２に基づくファームアップ手順（アップデートフロー）の作成手法の一例を説明する。

まず、運用コンソール２ａは、フローテーブルからメインルート（Route_001）のリスト構造体を取り出す。そして、運用コンソール２ａは、リスト構造体の先頭から処理要素（UP_UNIT_xxx等）を取り出し、取り出した順にフローを作成する。図１４の例では、運用コンソール２ａは、図７のRoute_001の１、２番目等において、UP_UNIT_001，UP_UNIT_002等のフローを作成する。

取り出した処理要素が分岐ポイントの場合（Branch_xx（Route_xxx，Route_xxx，…）、運用コンソール２ａは、パラメータで指定されたルートの分岐を作成する。図１４の例では、運用コンソール２ａは、図７のRoute_001の３、７番目において、Branch_01，Branch_02等の分岐を作成する。以降、分岐ルートに対しても、メインルートと同様に処理する。

取り出した処理要素が合流ポイントの場合（Join_xx（Base））、運用コンソール２ａは、分岐したルートの待ち合わせポイントを作成する。図１４の例では、運用コンソール２ａは、図７のRoute_001の６、９番目において、Join_01，Join_02等の待ち合わせポイントを作成する。

分岐ルートから取り出した処理要素が合流ポイントの場合（Join_xx（Route_xxx））、運用コンソール２ａは、指定された合流ポイントの待ち合わせに合流し、当該分岐ルートを終了させる。なお、メインルートには、他のルートに合流する合流ポイントとなる処理要素（Join_xx（Route_xxx））は存在しない。図１４の例では、分岐ルート（Route_002，Route_003）は、図７のRoute_002の３番目，Route_003の２番目において、それぞれRoute_001の６番目の待ち合わせポイント（Join_01（Base））に合流する。また、分岐ルート（Route_004）は、図７のRoute_004の２番目において、Route_001の９番目の待ち合わせポイント（Join_02（Base））に合流する。このとき、運用コンソール２ａは、Route_002〜Route_004を終了させる。

リスト構造体の全ての処理要素が取り出されたら、アップデートフローが完成する。なお、メインルート以外はいずれかのルートに合流して終了する。このように、図７に示すアップデートフローデータベース２２からアップデートフローを復元した場合、図１４に示すアップデートフローが確立されるのである。このアップデートフローは、図１に示すものと一致する。

運用コンソール２ａのファームアップ時間推定部２３は、上述のようにしてデータベース定義されたアップデートフローデータベース２２を使用し、総ファームアップ推定時間を自動で算出することができる。

なお、図３３及び図３４に示すように、複合システムのモデル情報が異なると、複合システムの構成部品も異なるため、アップデートフローも異なる。更新ファームセット３０の適用対象の複合システムに複数のモデルが存在し、それらに対応するアップデートフローが複数存在する場合、存在するアップデートフローの数だけアップデートフローデータベース２２が定義され、複合システムの管理を行なう管理サーバ上に格納される。

例えば、図１５に示すように、情報処理装置２は、１台で複数の対象装置１−１〜１−ｎ（ｎは自然数）の管理を行なうことも可能である。対象装置１−１〜１−ｎは、例えば互いにモデル／オプション等の装置構成が異なる。この場合、情報処理装置２の保持部２１には、全対象装置１−１〜１−ｎの各々に対応するアップデートフローデータベース２２−１〜２２−ｎが格納される。なお、図１５では、アップデートフローデータベース２２をＵＦＤＢ２２と表記している。

なお、アップデートフローデータベース２２−１〜２２−ｎは、それぞれ対応する対象装置１−１〜１−ｎのモデル／オプション等のモデルタイプ（装置構成）と対応付けられる。

以上のように、保持部２１は、互いに装置構成の異なる複数の仮想テープライブラリ装置１ａについて、各仮想テープライブラリ装置１ａが含む複数のモジュール１００ａに係る複数の更新処理の実行順序を示す情報（ＵＦＤＢ２２）を、装置構成と対応付けて保持するといえる。

〔２−２−２〕ファームアップ時間推定部の説明
次に、図６の説明に戻り、ファームアップ時間推定部２３の詳細について説明する。ファームアップ時間推定部２３は、ファームアップ対象の複合システムの総ファームアップ推定時間を算出する。

ファームアップ時間推定部２３は、例示的に、ＤＢ選択部２４、ブロック分割部２５、推定時間選択部２６、第１算出部２７、及び第２算出部２８をそなえる。

ＤＢ選択部２４は、ファームアップ対象の仮想テープライブラリ装置１ａのモデル用に用意されたアップデートフローデータベース２２を保持部２１から選択するアップデートフローデータベース選択処理を行なう。

ブロック分割部２５は、ＤＢ選択部２４により選択されたアップデートフローデータベース２２を、ブロック分割機能により、１つ又は複数の処理ブロックに分割するブロック分割処理を行なう。ここで、処理ブロックとは、複数の（一連の）部品ファームアップ処理を１つの部品ファームアップ処理と見做したブロックである。後述するように、処理ブロックには単一ルートブロックと複数ルートブロックとが含まれる。単一ルートブロックは、直列に（シーケンシャルに）更新処理を行なう単一ルートの部品ファームアップ処理を含む処理ブロックであり、複数ルートブロックは、並列に（並行して；パラレルに）更新処理を行なう複数ルートの部品ファームアップ処理を含む処理ブロックである。

推定時間選択部２６は、構成部品ごとのファームアップ推定時間を選択する機能を用いて、アップデートフローデータベース２２の部品ファームアップ処理（UP_UNIT_xxx）の各々に適切な部品のファームアップ推定時間を当て嵌めるファームアップ時間選択処理を行なう。

第１算出部２７は、推定時間選択部２６により当て嵌められた各部品のファームアップ処理時間から、処理ブロックごとのファームアップ推定時間を算出する機能を用いて、処理ブロックごとのファームアップにかかる処理時間を求めるブロック推定時間算出処理を行なう。

第２算出部２８は、第１算出部２７により求められた各処理ブロックの推定時間を加算し、当該アップデートフローを使用するモデルの総ファームアップ推定時間を求める。

ファームウェア更新処理部２９は、対象装置１としての仮想テープライブラリ装置１ａのファームアップを行なう場合、各フローテーブルで定義されたルート（Route_xxx）上で処理要素を指定された順に処理することで、ファームアップを行なう。ファームウェア更新処理部２９によれば、事前に定義されたアップデートフローデータベース２２に基づき自動でファームアップが行なえるため、作業者等による手動でのファームアップよりも正確且つ安全にファームアップを行なうことができる。なお、ファームウェア更新処理部２９の機能は運用コンソール２ａから省略してもよい。

以下、ファームアップ時間推定部２３がそなえる各構成の詳細について説明する。

（ＤＢ選択部２４の説明）
上述したように、アップデートフローデータベース２２は構成が異なるそれぞれのモデルタイプごとに存在し得る（図１５，図３３，図３４参照）。

仮想テープライブラリ装置１ａには、運用コンソール２ａからコマンドを発行することによって、モデル情報を取り出す機能が用意されていることが多い。従って、このコマンドを用いることで、対象装置１としての仮想テープライブラリ装置１ａがどのようなモデルタイプであるのかを判別することができる。なお、モデル情報としては、モデル／オプション、例えばモデル名やモデルＩＤ等のモデルタイプを識別可能な情報が挙げられる。

ＤＢ選択部２４は、このモデル情報取得機能を使用して、仮想テープライブラリ装置１ａのモデルタイプを取得し、取得したモデルタイプに対応するアップデートフローデータベース２２を保持部２１から選択する。

なお、仮想テープライブラリ装置１ａにモデルタイプを通知するコマンドが存在しない場合や、運用コンソール２ａがコマンドを発行したときに仮想テープライブラリ装置１ａがコマンドを受け付けない状態である場合等には、以下の手法を採ることもできる。例えば、予め対象装置１としての仮想テープライブラリ装置１ａの情報を定義する構成定義ファイルを作成し、この構成定義ファイルに仮想テープライブラリ装置１ａのモデル名を登録しておく。これにより、ＤＢ選択部２４は、モデル情報取得機能に代えて、仮想テープライブラリ装置１ａのモデル情報を判別し、対応するアップデートフローデータベース２２を選択することも可能である。

以上のように、ＤＢ選択部２４は、一の仮想テープライブラリ装置１ａから当該一の仮想テープライブラリ装置１ａの装置構成を示す情報を取得し、取得した装置構成に対応する実行順序を示す情報（ＵＦＤＢ）２２を保持部２１から取得する取得部の一例であるといえる。

（ブロック分割部２５の説明）
ブロック分割部２５は、アップデートフローデータベース２２を、以下の手順に従って１以上の処理ブロックに分割する。

一例として、ブロック分割部２５は、ＤＢ選択部２４が選択したアップデートフローデータベース２２のメインルートのリスト構造体について、更新順序に従って分岐ポイント（Branch_xx）に到達するまで順に読み込む。このとき、ブロック分割部２５は、分岐ポイントに到達するまでの一連の部品ファームアップ処理（UP_UNIT_xxx）については、直列に（シーケンシャルに）更新処理を行なう単一ルートの処理ブロック（単一ルートブロック，第２処理ブロック）と判断する。図１（図１４）の例では、図１６に示すように、部品１＋部品２（UP_UNIT_001＋UP_UNIT_002）が１つの単一ルートブロックと判断される。

分岐ポイントに到達すると、ブロック分割部２５は、当該分岐ポイントで分岐した全てのルートが再度合流して一つのルートに戻る合流ポイントまでを、並列に（並行して）更新処理を行なう複数ルートの処理ブロック（複数ルートブロック，第１処理ブロック）と判断する。図１（図１４）の例では、図１６に示すように、ポイント１〜ポイント２（Branch_01〜Join_01）の、部品３＋部品６、部品４＋部品７、並びに部品５（UP_UNIT_003＋UP_UNIT_006，UP_UNIT_004＋UP_UNIT_007，UP_UNIT_005）が１つの複数ルートブロックと判断される。また、図１（図１４）の他の例では、図１６に示すように、ポイント３〜ポイント４（Branch_02〜Join_02）の、部品８＋部品９（UP_UNIT_008＋UP_UNIT_009）が１つの複数ルートブロックと判断される。

なお、複数ルートブロック内で分岐したブロックルートが、他のルートの合流前に再分岐した場合、ブロック分割部２５は、再分岐した全てのブロックルートが合流するまでを１つの処理ブロックと判断する。

例えば、図１７に示すように、Branch_0aにおいて部品Ａ＋部品Ｃ、部品Ｂの２つのルートに分岐した後、部品Ｂが部品Ａ＋部品Ｃに合流する前に、Branch_0bで部品Ｄ、部品Ｅ＋部品Ｇに分岐することがある。なお、部品ＤはJoin_0aで部品Ａ＋部品Ｃと合流し、部品Ｅ＋部品ＧはJoin_0bで部品Ｄに続く部品Ｆと合流する。このような場合、ブロック分割部２５は、最初の分岐ポイント（Branch_0a）から全ての分岐ルートが合流する合流ポイント（Join_0b）までを１つの複数ルートブロックと判断する。

また、ブロック分割部２５は、複数ルートブロックと判断した処理ブロックについて、当該処理ブロックの先頭から末尾の間の全てのルートをブロックルートとして定義（特定）する。図１（図１４）の例では、図１８に示すように、ポイント１からポイント２まで（Branch_01〜Join_01）の処理ブロックは、部品３＋部品６のルート（Route_001）、部品４＋部品７のルート（Route_002）、及び部品５のルート（Route_003）の３ルートが、ブロックルートとして定義される。また、図１（図１４）の他の例では、図１８に示すように、ポイント３からポイント４まで（Branch_02〜Join_02）の処理ブロックは、部品８のルート（Route_001）及び部品９のルート（Route_004）の２ルートが、ブロックルートとして定義される。

また、処理ブロック内で、再分岐が行なわれて分岐ポイントが複数存在したり、合流ポイントが複数存在する場合、特定のファームアップ処理（UP_UNIT_xxx）が、２以上のブロックルートに含まれてもよい。

図１７の例では、図１９に示すように、部品Ａ＋部品Ｃ＋部品Ｆのルート（Route_00aの少なくとも一部）、部品Ｂ＋部品Ｄ＋部品Ｆのルート（Route_00bの少なくとも一部）、部品Ｂ＋部品Ｅ＋部品Ｇのルート（Route_00cの少なくとも一部）の３ルートが、ブロックルートとして定義される。

ブロック分割部２５は、上述のようにしてブロック分割を行なうと、アップデートフローデータベース２２のフローテーブルに対して、各処理要素がいずれの処理ブロックに属するかを特定する情報を設定してよい。ブロック分割部２５により加工されたアップデートフローデータベース２２は、以降の推定時間選択部２６及び第１算出部２７の処理においても利用される。なお、ブロック分割部２５は、アップデートフローデータベース２２（フローテーブル）のコピーを作成し、当該コピーにアップデートフローを分割して得られた処理ブロックの情報を設定することが好ましい。

なお、ブロック分割部２５は、アップデートフローデータベース２２に含まれる複数のモジュール１００ａ（の更新処理）から、シーケンシャルに実行される一以上の更新処理、つまり単一ルートブロック（第２処理ブロック）の定義（特定）を行なわなくてもよい。単一ルートブロックは、当該処理ブロック内の複数のモジュール１００ａの更新処理が直列に行なわれるため、これらのモジュール１００ａの各々を個々の処理ブロックと見做しても、総ファームアップ推定時間の算出結果に与える影響が少ないためである。

換言すれば、ブロック分割部２５は、アップデートフローデータベース２２に含まれる複数のモジュール１００ａ（の更新処理）から、少なくとも複数ルートブロック（第１処理ブロック）を特定すればよい。なお、ブロック分割部２５は、複数ルートブロックとともに単一ルートブロックの特定についても行なうことにより、第１算出部２７及び第２算出部２８の処理負荷を低減させることができる。

以上のように、ブロック分割部２５は、実行順序を示す情報（ＵＦＤＢ）２２に基づき、複数の更新処理（処理要素）から、並行して実行される複数の更新処理を１つの処理ブロックとした１以上の第１処理ブロックを特定する特定部の一例であるといえる。

（推定時間選択部２６の説明）
仮想テープライブラリ装置１ａに含まれる個々の部品（モジュール１００ａ）のファームアップにかかる更新時間（ファームアップ時間）は、アップデートされるファームウェアの機能やプログラムの性能等によって異なる場合がある。個々の部品のファームアップ時間が異なると、総ファームアップ推定時間にも誤差が生じ得る。

また、個々の部品のファームアップ方式は、部品によって多様であり、例えばファームウェア全体を置き換える（上書きする）方式のほか、旧版からの差分のみを更新する差分ファームアップ方式が用いられる場合もある。差分ファームアップ方式の場合、現在運用中の部品のファーム版数によって、ファームアップにかかる更新時間が変化し得る。

さらに、仮想テープライブラリ装置１ａの全ての部品（モジュール１００ａ）のファームウェアがアップデートされるとは限らない。

ところで、複合システムのファームウェア管理では、過去にリリースされた複合システムのファーム版数と、今回リリースされるファーム版数とについて、それぞれの部品のファーム版数が管理されていることが多い。すなわち、過去にリリースされた（適用された）複合システムのファーム版数から、今回のファーム版数にファームアップする場合、複合システムの各々の部品のファーム版数が何版から何版にファームアップされるのかが、ファーム管理情報として管理されている。

そこで、一実施形態に係るシステムでは、このファーム管理情報を拡張し、総ファームアップ推定時間をより正確に求めるために、更新ファームセット３０に構成部品（モジュール１００ａ）ごとのファームアップ時間データベース３２を追加する（図６参照）。

ファームアップ時間データベース３２は、図２０に例示するように、部品（モジュール１００ａ）ごとに、現在の運用版数から更新ファームセット３０に含まれるファームウェアデータ３１の版数にファームアップする場合の更新時間が設定される。一例として、図２０に示すように、部品１（UP_UNIT_001）のファームアップにかかる更新時間は、運用版数が○○版の場合ＸＸ分、運用版数が□□版の場合ＹＹ分、運用版数が△△版の場合ＺＺ分となる。

ファームアップ時間データベース３２は、対象装置１としての仮想テープライブラリ装置１ａのファームリリース（更新ファームセット３０の提供）の際に、更新ファームセット３０に含まれる。

推定時間選択部２６は、所定のコマンドを用いて、対象装置１としての仮想テープライブラリ装置１ａから現行の運用版数を取得する。そして、推定時間選択部２６は、保持部２１からファームアップ時間データベース３２を読み出し、仮想テープライブラリ装置１ａの運用版数に対応する各部品の更新時間を、ブロック分割部２５が加工したアップデートフローデータベース２２に適用（設定）する。これにより、第１算出部２７及び第２算出部２８では、提供された更新ファームセット３０を仮想テープライブラリ装置１ａのモデルに適用する場合の総ファームアップ推定時間を、より正確に求めることができる。

（第１算出部２７の説明）
第１算出部２７は、ブロック分割部２５が分割した処理ブロックごとのファームアップにかかる更新時間を算出する。

例えば、第１算出部２７は、アップデートフローデータベース２２を参照し、ブロック分割部２５が設定した処理ブロックごとに、当該処理ブロック内の各モジュール１００ａの更新時間を用いて当該処理ブロックの全体の更新時間を算出する。

一例として、単一ルートブロックは、当該処理ブロック内のモジュール１００ａが直列的に（１つずつ順に）更新される。従って、第１算出部２７は、単一ルートブロックについては、当該処理ブロック内の各モジュール１００ａの更新時間の合計を算出すればよい。

一方、複数ルートブロックは、当該処理ブロック内のモジュール１００ａが並列的に（並行して）更新される。従って、複数ルートブロックの更新時間については、当該処理ブロックに定義されたブロックルートごとの更新時間が最も大きな値を持つブロックルート（最もファームアップの合計時間が大きいブロックルート）が、当該処理ブロックの更新時間となる。そこで、第１算出部２７は、複数ルートブロックのブロックルートごとに、当該ブロックルートに含まれる各モジュール１００ａの更新時間の合計を算出し、最も大きい合計時間を複数ルートブロックの更新時間とすればよい。

第１算出部２７は、上述のようにして算出した処理ブロックごとの更新時間を、アップデートフローデータベース２２に設定する。例えば、ブロック分割部２５がアップデートフローデータベース２２のフローテーブルに処理ブロックの情報を設定しているため、この情報に対して処理ブロックごとの更新時間を追記してもよい。

以上のように、推定時間選択部２６及び第１算出部２７は、複数の更新処理（処理要素）の各々にかかる更新時間を示す情報（ファームアップ時間ＤＢ）３２を用いて、ブロック分割部２５が特定した複数ルートブロックごとの更新時間を推定する第１推定部の一例であるといえる。

また、推定時間選択部２６及び第１算出部２７は、ブロック分割部２５が特定した複数ルートブロックにおいて並行して更新処理が実行されるルートごとの更新時間を推定し、ルートごとに推定した更新時間のうちの最長の更新時間を当該複数ルートブロックの更新時間として推定する。これにより、更新処理が分岐する場合でも、当該複数ルートブロックについて、正確にファームアップ推定時間を算出することができる。

（第２算出部２８の説明）
第２算出部２８は、第１算出部２７が算出した処理ブロックごとの更新時間に基づき、対象装置１としての仮想テープライブラリ装置１ａの総ファームアップ推定時間を算出する。

上述のように、第１算出部２７によって、各処理ブロック（単一ルートブロック及び複数ルートブロック）の更新時間が算出されている。従って、第２算出部２８は、これらの更新時間を合計することで、仮想テープライブラリ装置１ａ全体のファームアップ時間を算出することができる。

このように、第２算出部２８は、更新時間を示す情報（ファームアップ時間ＤＢ）３２及び推定時間選択部２６及び第１算出部２７が推定した第１処理ブロックごとの更新時間の少なくとも一方に基づいて、仮想テープライブラリ装置１ａの更新時間を推定する第２推定部の一例であるといえる。例えば、第２算出部２８は、推定時間選択部２６及び第１算出部２７が推定した複数ルートブロックごとの更新時間及び単一ルートブロックごとの更新時間を合計する。これにより、仮想テープライブラリ装置１ａの更新時間を正確に推定することができる。

運用コンソール２ａは、上述のようにして推定した総ファームアップ推定時間を、作業者へ出力する。出力の手法としては、例えばモニタ等の出力装置への表示、ファイルへの格納、電子メールの送信等、既知の種々の手法を用いることができる。

以上のように、一実施形態に係るシステム（情報処理装置２）によれば、データベース定義したアップデートフローを使用することで、対象装置１の総ファームアップ推定時間の算出を自動化することができる。これにより、ファームアップの作業者の負荷を減らし、正確且つ安全に、対象装置１（複合システム）のファームアップにかかる時間（総ファームアップ推定時間）を導出することができる。

上述したように、総ファームアップ推定時間は、ファームアップの作業者がアップデートフローを参照して机上シミュレートを行なって求めることが考えられる。

これに対し、一実施形態に係るシステムでは、情報処理装置２が、ファームアップを行なうルートが設定されたアップデートフローのデータベース２２を、モデル（構成）ごとに管理する。情報処理装置２は、このデータベース２２を用いて、対象装置１のファームアップにおいて並列処理が可能なモジュール１００ａを処理ブロックとして分割することができる。従って、情報処理装置２は、複雑なアップデートフローを持つ対象装置１であっても、ファームアップの並列処理を考慮することで、総ファームアップ推定時間の算出を容易に行なうことができる。

また、情報処理装置２としての機能は、図５に示すように、例えば対象装置１としての仮想テープライブラリ装置１ａを管理する管理サーバに集約することができる。管理対象となる仮想テープライブラリ装置１ａ（複合システム）では、管理サーバとのインタフェースを介して管理サーバにより制御され、総ファームアップ推定時間の算出が行なわれる。従って、ファームアップ時間推定部２３の処理に伴う管理サーバからの指示、複合システムでの処理、複合システムから管理サーバへの応答等は、既存のインタフェースを用いて実行されてよい。これにより、情報処理装置２に所定のプログラム（更新時間推定プログラム）を設定するだけで、上述した機能を実現することができ、コストの増加を抑制することができる。

〔２−３〕動作例
次に、上述の如く構成されたシステムの情報処理装置２（運用コンソール２ａ）の動作例を、図２１〜図２５を参照して説明する。

はじめに、図２１を参照して、ファームアップ時間推定部２３による全体の処理（更新時間推定処理）について説明する。

まず、ＤＢ選択部２４は、ファームアップの対象モデル（仮想テープライブラリ装置１ａ）のアップデートフローデータベース２２を選択する（ステップＳ１）。

次いで、ブロック分割部２５は、アップデートフローデータベース２２を１以上の処理ブロックに分割する（ステップＳ２）。

次に、推定時間選択部２６は、アップデートフローデータベース２２における各部品のファームアップ時間をファームアップ時間データベース３２から選択し、アップデートフローデータベース２２に設定する（ステップＳ３）。

そして、第１算出部２７は、ファームアップ推定時間を処理ブロック単位で求める（ステップＳ４）。

最後に、第２算出部２８は、メインルートの処理ブロック（第１算出部２７が決定した処理ブロック）の推定時間を加算（合計）して、総ファームアップ推定時間を求め（ステップＳ５）、処理が終了する。

次に、図２２を参照して、ＤＢ選択部２４によるＤＢ選択処理（図２１のステップＳ１）について説明する。

ＤＢ選択部２４は、ファームアップの対象装置１である仮想テープライブラリ装置１ａに装置モデル情報の取得コマンドを発行して、モデル情報を取得する（ステップＳ１１）。

取得コマンドによりモデル情報が取得できた場合（ステップＳ１２，Ｓ１２のＹｅｓルート）、ＤＢ選択部２４は、対応するアップデートフローデータベース２２が保持部２１に保持されているか否かを判断する（ステップＳ１３）。保持されている場合（ステップＳ１３のＹｅｓルート）、ＤＢ選択部２４は、適合するアップデートフローデータベース２２を選択し（ステップＳ１４）、処理が終了する。

一方、ステップＳ１３において対応するアップデートフローデータベース２２が保持部２１に保持されていない場合（ステップＳ１３のＮｏルート）、データベース選択不可として、処理がエラー終了する。

また、ステップＳ１２において、取得コマンドによりモデル情報を取得していない場合（ステップＳ１２のＮｏルート）、ＤＢ選択部２４は、構成定義ファイルからモデル情報を取得できるか否かを判断する（ステップＳ１５）。構成定義ファイルからモデル情報を取得できる場合（ステップＳ１５のＹｅｓルート）、処理がステップＳ１３に移行する。

一方、ステップＳ１５において構成定義ファイルからモデル情報が取得されない場合（ステップＳ１５のＮｏルート）、構成定義ファイルがない、又は、構成定義ファイルに対象装置１のモデル情報が登録されていないため、データベース選択不可として、処理がエラー終了する。

ＤＢ選択部２４は、以上の処理によって選択したアップデートフローデータベース２２を対象装置１のアップデートフローデータベース２２として決定する。

次に、図２３を参照して、ブロック分割部２５によるブロック分割処理（図２１のステップＳ２）について説明する。なお、前提として、ブロック分割部２５は、ＤＢ選択部２４が選択したアップデートフローデータベース２２のフローテーブルからメインルートのリスト構造体を順に読み出しているものとする。

まず、ブロック分割部２５は、フローテーブルにおいて、現在のルートの位置が分岐ポイント（Branch_xx）であるか否かを判断する（ステップＳ２１）。現在のルートの位置が分岐ポイント（Branch_xx）である場合（ステップＳ２１のＹｅｓルート）、ブロック分割部２５は、分岐した全てのルートが再度合流して１つのルートに戻る合流ポイントまでを１つの処理ブロックとして定義する（ステップＳ２２）。なお、この処理ブロックは複数ルートブロックとなる。

なお、分岐したブロックルートが他のルートの合流前に再分岐した場合、ブロック分割部２５は、その再分岐した全てのブロックルートが合流するまでを１つの処理ブロックとする。

次いで、ブロック分割部２５は、複数ルートブロックとして定義した処理ブロックで、処理ブロックの先頭から終了までの全てのルートをブロックルートとして定義し（ステップＳ２３）、処理がステップＳ２５に移行する。

一方、ステップＳ２１において、現在のルートの位置が分岐ポイント（Branch_xx）ではない場合（ステップＳ２１のＮｏルート）、ブロック分割部２５は、次に存在する分岐ポイント又は終了ポイントまでを１つの処理ブロックとして定義し（ステップＳ２４）、処理がステップＳ２５に移行する。なお、この処理ブロックは単一ルートブロックとなる。

ステップＳ２５では、ブロック分割部２５は、分割処理が終了ポイント（メインルートのリスト構造体の最終行）まで進んだか否かを判断し、分割処理が終了ポイントまで処理された場合（ステップＳ２５のＹｅｓルート）、処理が終了する。

一方、分割処理が終了ポイントまで処理されていない場合（ステップＳ２５のＮｏルート）、処理がステップＳ２１に移行する。

次に、図２４を参照して、推定時間選択部２６によるファームアップ時間選択処理（図２１のステップＳ３）について説明する。

推定時間選択部２６は、ファームアップの対象装置１としての仮想テープライブラリ装置１ａから、現在運用中の版数情報を、所定のコマンドの発行を通じて取得する（ステップＳ３１）。なお、版数情報の取得は、ＤＢ選択部２４による仮想テープライブラリ装置１ａのモデル情報の取得と同様のタイミングで行なわれてもよい。

次いで、推定時間選択部２６は、更新ファームセット３０に追加された、ファームアップ時間データベース３２を取り込む（ステップＳ３２）。なお、推定時間選択部２６は、運用コンソール２ａが事前に更新ファームセット３０の情報を保持部２１に保持している場合には、保持部２１からファームアップ時間データベース３２を取得してもよい。

また、推定時間選択部２６は、ファームアップ時間データベース３２から、ステップＳ３１で取得した仮想テープライブラリ装置１ａの運用版数に対応する各部品のファームアップ時間を抽出する（ステップＳ３３）。

そして、推定時間選択部２６は、アップデートフローデータベース２２に対して、ステップＳ３３で抽出した各部品のファームアップ時間を当て嵌めて（ステップＳ３４）、処理が終了する。

次に、図２５を参照して、第１算出部２７によるブロック推定時間算出処理（図２１のステップＳ４）について説明する。なお、図２５の処理は、ブロック分割部２５が特定した処理ブロックの数分繰り返し実行される。

まず、第１算出部２７は、推定時間を求める処理ブロックが単一ルートブロック（処理ブロック内にブロックルートが１本のみ存在する）か否かを判断する（ステップＳ４１）。処理ブロックが単一ルートブロックである場合（ステップＳ４１のＹｅｓルート）、第１算出部２７は、当該処理ブロックに含まれる部品のファームアップ時間を全て加算し、その加算値を処理ブロックの推定時間として（ステップＳ４２）、当該処理ブロックのブロック推定時間の算出を終了する。

一方、処理ブロックが単一ルートブロックではない場合（ステップＳ４１のＮｏルート）、第１算出部２７は、当該処理ブロックは複数ルートブロックであると判断し、当該処理ブロックに含まれる全てのブロックルートについての推定時間を、ステップＳ４２と同様の手法で求める。そして、第１算出部２７は、推定時間を求めた全てのブロックルートのうち、最も加算値の大きなブロックルートの推定時間を当該処理ブロックの推定時間として（ステップＳ４３）、当該処理ブロックのブロック推定時間の算出を終了する。

〔２−４〕実施例
次に、上述の如く構成された一実施形態に係るシステムの実施例について説明する。なお、前提として、対象装置１の一例としての仮想テープライブラリ装置１ａは、部品１〜部品９の９個の部品を含み、図２６に例示するアップデートフローを持つものとする。また、ファームアップ時間データベース３２は、図２７に例示するものであるとする。

〔２−４−１〕第１実施例
はじめに、図２８及び図２９を参照して、仮想テープライブラリ装置１ａを０１版から更新ファームセット３０の最新版へファームアップする場合について説明する。

図２６に示すアップデートフローの場合、図２７に示すファームアップ時間データベース３２に従って、現行運用版数が０１版からリリースされた版数にファームアップされる場合のアップデートフローデータベース２２（フローテーブル）は、図２８に示すものとなる。

すなわち、図２８に例示するように、ブロック分割部２５により、図７に示す基本のアップデートフローデータベース２２のフローテーブル（又はコピー）に、アップデートフローを分割して得られた処理ブロック（図２８中、“処理ブロック”と表記）情報が設定される。また、推定時間選択部２６により、当該フローテーブルに、選択した各部品のファームアップ時間（図２８中、“推定時間”と表記）情報が設定される。さらに、第１算出部２７により、当該フローテーブルの処理ブロック情報に、処理ブロックごとの推定時間（図２８中、“処理ブロック［推定時間］”と表記）が設定される。

図２８に示すように、ブロック分割部２５は、仮想テープライブラリ装置１ａのアップデートフローを処理ブロックＡ、処理ブロックＢ、処理ブロックＣの３つの処理ブロックに分割する。

図２９に例示するように、処理ブロックＡは、単一ルートブロックであるため、第１算出部２７は、部品１及び部品２のファームアップ時間を加算したトータル時間として２０分＋１０分＝３０分を得る。

処理ブロックＢは、複数ルートブロックである。部品３及び部品６のファームアップが実施されるブロックルートは８０分＋４０分＝１２０分、部品４及び部品７のファームアップが実施されるブロックルートは６０分＋５０分＝１１０分、部品５のファームアップが実施されるブロックルートは１００分である。第１算出部２７は、これらの時間を算出し、最大値である部品３及び部品６のファームアップが実施されるブロックルートの１２０分を、処理ブロックＢの推定時間と決定する。

同様に、処理ブロックＣは、複数ルートブロックであり、第１算出部２７は、部品９のブロックルートにかかる６０分を、処理ブロックＣの推定時間と決定する。

このようにして、推定時間選択部２６及び第１算出部２７は、処理ブロックＡについてRoute_001の３０分、処理ブロックＢについてRoute_001の１２０分、処理ブロックＣについてRoute_004の６０分を、それぞれ各処理ブロックの（最長の）推定時間として算出（決定）する。

第２算出部２８は、全ての処理ブロックの推定時間を加算し、３０分＋１２０分＋６０分＝２１０分を得る。

以上のように、第１実施例では、運用版数の０１版からリリースされた版数へのファームアップにかかる総ファームアップ推定時間が２１０分と導出される。

〔２−４−２〕第２実施例
次に、図３０及び図３１を参照して、仮想テープライブラリ装置１ａを０３版から更新ファームセット３０の最新版へファームアップする場合について説明する。

第１実施例と同様に、図２６に示すアップデートフローの場合、図２７に示すファームアップ時間データベース３２に従って、現行運用版数が０３版からリリースされた版数にファームアップされる場合のアップデートフローデータベース２２（フローテーブル）は、図３０に示すものとなる。

図２７に示すように、現行運用版数が０３版の場合、部品４及び部品９ではファームアップ時間が０分、つまりファームアップが不要となる。また、部品１〜部品３、部品５、部品６、部品８についても、現行運用版数が０１版のときよりもファームアップ時間が短縮される。

この場合、図３１に例示するように、処理ブロックＡについて、第１算出部２７は、部品１及び部品２のファームアップ時間を加算したトータル時間として１３分＋９．５分＝２２．５分を得る。

処理ブロックＢは、部品３及び部品６のファームアップが実施されるブロックルートが４５分＋２５分＝７０分、部品４及び部品７のファームアップが実施されるブロックルートが０分＋５１分＝５１分、部品５のファームアップが実施されるブロックルートが９０分である。第１算出部２７は、これらの時間を算出し、最大値である部品５のファームアップが実施されるブロックルートの９０分を、処理ブロックＢの推定時間と決定する。

同様に、処理ブロックＣについて、第１算出部２７は、部品８のブロックルートにかかる３２分を、処理ブロックＣの推定時間と決定する。

このようにして、推定時間選択部２６及び第１算出部２７は、処理ブロックＡについてRoute_001の２２．５分、処理ブロックＢについてRoute_003の９０分、処理ブロックＣについてRoute_001の３２分を、それぞれ各処理ブロックの（最長の）推定時間として算出（決定）する。

第２算出部２８は、全ての処理ブロックの推定時間を加算し、２２．５分＋９０分＋３２分＝１４４．５分を得る。

以上のように、第１実施例では、運用版数の０３版からリリースされた版数へのファームアップにかかる総ファームアップ推定時間が１４４．５分と導出される。

以上のように、一実施形態に係る運用コンソール２ａでは、仮想テープライブラリ装置１ａの装置ファームアップにおいて、データベース化されたアップデートフローを使用して、更新ファームセット３０に追加されたファームアップ時間データベース３２を取り込む。これにより、運用コンソール２ａは、仮想テープライブラリ装置１ａに更新ファームセット３０を適用する正確な総ファームアップ推定時間を自動で求めることができるため、作業者は、対象装置１のファームアップスケジュールを無駄のない時間帯で立案することができ、ファームアップに伴う対象装置１の可用性の低下を抑制することもできる。

また、人手で実施するファームアップ実施前の机上シミュレーションを不要とすることができるため、より短期間で対象装置１のファームアップスケジュールを立案することができる。

〔３〕ハードウェア構成例
図３２に示すように、上述した一実施形態に係る運用コンソール２ａ（情報処理装置２）は、ＣＰＵ２０ａ、メモリ２０ｂ、記憶部２０ｃ、インタフェース部２０ｄ、入出力部２０ｅ、及び読取部２０ｆをそなえることができる。

ＣＰＵ２０ａは、種々の制御や演算を行なう演算処理装置（プロセッサ）の一例である。ＣＰＵ２０ａは、対応する各ブロック２０ｂ〜２０ｆと接続され、メモリ２０ｂ、記憶部２０ｃ、記録媒体２０ｇ、又は図示しないＲＯＭ（Read Only Memory）等に格納されたプログラムを実行することにより、種々の機能を実現することができる。

メモリ２０ｂは、種々のデータやプログラムを格納する記憶装置である。ＣＰＵ２０ａは、プログラムを実行する際に、メモリ２０ｂにデータやプログラムを格納し展開する。なお、メモリ２０ｂとしては、例えばＲＡＭ（Random Access Memory）等の揮発性メモリが挙げられる。

記憶部２０ｃは、種々のデータやプログラム等を格納するハードウェアである。記憶部２０ｃとしては、例えばＨＤＤ等の磁気ディスク装置、ＳＳＤ等の半導体ドライブ装置、フラッシュメモリやＲＯＭ等の不揮発性メモリ等の各種装置が挙げられる。なお、図６に示す保持部２１は、メモリ２０ｂ又は記憶部２０ｃにより実現されてよい。

例えば、記憶部２０ｃは、運用コンソール２ａの各種機能の全部もしくは一部を実現する更新時間推定プログラム２００及び１以上のアップデートフローデータベース２２を格納することができる。また、記憶部２０ｃは、提供された更新ファームセット３０に含まれる複数のファームウェアデータ３１及びファームアップ時間データベース３２を格納することができる。

インタフェース部２０ｄは、有線又は無線による、対象装置１としての仮想テープライブラリ装置１ａ及びネットワークや他の情報処理装置等との間の接続及び通信の制御等を行なう通信インタフェースである。インタフェース部２０ｄとしては、例えば、ＬＡＮ、ＦＣ、インフィニバンド（InfiniBand）等に準拠したアダプタが挙げられる。例えば、ＣＰＵ２０ａは、インタフェース部２０ｄを介してネットワークから取得した端末プログラム２００を記憶部２０ｃに格納してもよい。

入出力部２０ｅは、マウス、キーボード、タッチパネル、音声操作のためのマイク等の入力装置（操作部）、並びにディスプレイ、スピーカー、及びプリンタ等の出力装置（出力部、表示部）の少なくとも一方を含むことができる。例えば、入力装置はファームアップの作業者や仮想テープライブラリ装置１ａの管理者等による運用コンソール２ａの各種操作やデータの入力等の作業に用いられてよく、出力装置は総ファームアップ推定時間の算出結果や各種通知等の出力に用いられてよい。

読取部２０ｆは、コンピュータ読取可能な記録媒体２０ｇに記録されたデータやプログラムを読み出す装置である。この記録媒体２０ｇには端末プログラム２００が格納されてもよい。

例えば、ＣＰＵ２０ａは、記憶部２０ｃに格納された端末プログラム２００を、メモリ２０ｂ等の記憶装置に展開して実行することにより、運用コンソール２ａのファームアップ時間推定部２３（及びファームウェア更新処理部２９）の機能を実現することができる。

なお、記録媒体２０ｇとしては、例えばフレキシブルディスク、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）、ブルーレイディスク等の光ディスクや、ＵＳＢ（Universal Serial Bus）メモリやＳＤカード等のフラッシュメモリが挙げられる。なお、ＣＤとしては、ＣＤ−ＲＯＭ、ＣＤ−Ｒ（CD-Recordable）、ＣＤ−ＲＷ（CD-Rewritable）等が挙げられる。また、ＤＶＤとしては、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、ＤＶＤ＋Ｒ、ＤＶＤ＋ＲＷ等が挙げられる。

上述した各ブロック２０ａ〜２０ｆ間はそれぞれバスで相互に通信可能に接続される。また、運用コンソール２ａの上述したハードウェア構成は例示である。従って、運用コンソール２ａ内でのハードウェアの増減（例えば任意のブロックの追加や省略）、分割、任意の組み合わせでの統合、バスの追加又は省略等は適宜行なわれてもよい。

〔４〕その他
以上、本発明の好ましい実施形態について詳述したが、本発明は、かかる特定の実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲内において、種々の変形、変更して実施することができる。

例えば、図６に示す運用コンソール２ａの各機能ブロックは、任意の組み合わせで併合してもよく、分割してもよい。

また、上述した説明では、ファームアップ時間データベース３２における現行の運用版数が、仮想テープライブラリ装置１ａ全体のファームウェアの版数であるものとして説明したが、これに限定されるものではない。例えば、現行の運用版数は、部品（モジュール１００ａ）ごとのファームウェアの運用版数であってもよい。この場合、ファームアップ時間データベース３２で参照される現行の運用版数の列は、部品ごとに異なる列となり得る。

さらに、仮想テープライブラリ装置１ａのアップデートフローは、基本的にはモデルタイプ（装置構成）等に従って決定されるため、ブロック分割処理で定義された処理ブロックの情報やブロックルート情報を含むアップデートフローデータベース２２は頻繁に更新しなくてもよい。

すなわち、アップデートフローのデータベース２２と、このアップデートフローからブロック分割部２５により作成される処理ブロック情報が含まれたアップデートフローデータベース２２は、運用コンソール２ａに常時保持され得る。運用コンソール２ａに接続されている仮想テープライブラリ装置１ａは構成が基本的に固定であるためである。

なお、仮想テープライブラリ装置１ａのファームアップに伴い、ファームアップの手順自体が変更される場合がある。この場合、アップデートフローの変更となるため、運用コンソール２ａは、別途、更新ファームセット３０とともに、アップデートされたアップデートフローがベンダ等の開発元から提供され、運用コンソール２ａ内のデータベース２２が更新される。この場合、運用コンソール２ａでは、再度、ＤＢ選択部２４によるＤＢ選択処理やブロック分割部２５によるブロック分割処理が実行され、処理ブロック情報やブロックルート情報が再生成される。

一方、ファームアップ時間データベース３２については、仮想テープライブラリ装置１ａのファームリリースごとに最新のデータベース３２が更新ファームセット３０に含められ提供される。従って、ファームアップ時間データベース３２は、運用コンソール２ａが更新ファームセット３０を受領する都度更新されることが好ましい。

以上のことから、ＤＢ選択部２４及びブロック分割部２５の処理（図２１のステップＳ１及びＳ２の処理、並びに図２２及び図２３の処理）は、仮想テープライブラリ装置１ａのアップデートフロー一覧の更新があった場合に実行されればよい。一方、推定時間選択部２６、第１算出部２７、及び第２算出部２８の処理（図２１のステップＳ３〜Ｓ５の処理、並びに図２４及び図２５の処理）は、更新ファームセット３０を受領した都度（ファームアップ処理を実行する都度）、実行されることが好ましい。

以上のように、仮想テープライブラリ装置１ａは、ファームウェアが新たにリリースされると、更新ファームセット３０に含まれるファームアップ時間データベース３２を用いて、ファームアップ時間推定部２３により、総ファームアップ推定時間を求める。

〔４〕付記
以上の実施形態に関し、更に以下の付記を開示する。

（付記１）
ソフトウェアの更新処理が行なわれるモジュールを複数含む対象装置に対応した、前記複数のモジュールに係る複数の更新処理の実行順序を示す情報に基づき、前記複数の更新処理から、並行して実行される複数の更新処理を一処理ブロックとした一以上の第１処理ブロックを特定する特定部と、
前記複数の更新処理の各々にかかる更新時間を示す情報を用いて、前記特定部が特定した第１処理ブロックごとの更新時間を推定する第１推定部と、
更新時間を示す情報及び前記第１推定部が推定した第１処理ブロックごとの更新時間の少なくとも一方に基づいて、前記対象装置の更新時間を推定する第２推定部と、をそなえる
ことを特徴とする、情報処理装置。

（付記２）
前記第１推定部は、前記更新時間を示す情報を用いて、前記特定部が特定した第１処理ブロックにおいて並行して更新処理が実行されるルートごとの更新時間を推定し、ルートごとに推定した更新時間のうちの最長の更新時間を当該第１処理ブロックの更新時間として推定する、
ことを特徴とする、付記１記載の情報処理装置。

（付記３）
前記特定部は、前記実行順序を示す情報に基づき、前記複数の更新処理から、シーケンシャルに実行される一以上の更新処理を一処理ブロックとした一以上の第２処理ブロックを特定し、
前記第１推定部は、前記更新時間を示す情報を用いて、前記特定部が特定した第２処理ブロックにおける更新処理の更新時間を合計し、合計した更新時間を当該第２処理ブロックの更新時間と推定し、
前記第２推定部は、前記第１推定部が推定した第１処理ブロックごとの更新時間及び第２処理ブロックごとの更新時間を合計することで、前記対象装置の更新時間を推定する、
ことを特徴とする、付記２記載の情報処理装置。

（付記４）
互いに装置構成の異なる複数の対象装置について、各対象装置が含む複数のモジュールに係る複数の更新処理の実行順序を示す情報を、装置構成と対応付けて保持する保持部と、
一の対象装置から当該一の対象装置の装置構成を示す情報を取得し、取得した装置構成に対応する実行順序を示す情報を前記保持部から取得する取得部と、をさらにそなえる
ことを特徴とする、付記１〜付記３のいずれか１項記載の情報処理装置。

（付記５）
前記更新時間を示す情報には、更新前のソフトウェアの版数ごとに更新時間が設定され、
前記第１推定部は、一の対象装置から当該一の対象装置に係る更新前のソフトウェアの版数を示す情報を取得し、取得した情報が示す版数に対応する更新時間を、前記更新時間を示す情報から抽出し、抽出した更新時間を用いて前記推定を行なう、
ことを特徴とする、付記１〜付記４のいずれか１項記載の情報処理装置。

（付記６）
コンピュータに、
ソフトウェアの更新処理が行なわれるモジュールを複数含む対象装置に対応した、前記複数のモジュールに係る複数の更新処理の実行順序を示す情報に基づき、前記複数の更新処理から、並行して実行される複数の更新処理を一処理ブロックとした一以上の第１処理ブロックを特定し、
前記複数の更新処理の各々にかかる更新時間を示す情報を用いて、前記特定した第１処理ブロックごとの更新時間を推定し、
更新時間を示す情報及び前記推定した第１処理ブロックごとの更新時間の少なくとも一方に基づいて、前記対象装置の更新時間を推定する、
処理を実行させることを特徴とする、更新時間推定プログラム。

（付記７）
前記コンピュータに、
前記更新時間を示す情報を用いて、前記特定した第１処理ブロックにおいて並行して更新処理が実行されるルートごとの更新時間を推定し、ルートごとに推定した更新時間のうちの最長の更新時間を当該第１処理ブロックの更新時間として推定する、
処理を実行させることを特徴とする、付記６記載の更新時間推定プログラム。

（付記８）
前記コンピュータに、
前記実行順序を示す情報に基づき、前記複数の更新処理から、シーケンシャルに実行される一以上の更新処理を一処理ブロックとした一以上の第２処理ブロックを特定し、
前記更新時間を示す情報を用いて、前記特定した第２処理ブロックにおける更新処理の更新時間を合計し、合計した更新時間を当該第２処理ブロックの更新時間と推定し、
前記推定した第１処理ブロックごとの更新時間及び第２処理ブロックごとの更新時間を合計することで、前記対象装置の更新時間を推定する、
処理を実行させることを特徴とする、付記７記載の更新時間推定プログラム。

（付記９）
前記コンピュータに、
一の対象装置から当該一の対象装置の装置構成を示す情報を取得し、
互いに装置構成の異なる複数の対象装置について、各対象装置が含む複数のモジュールに係る複数の更新処理の実行順序を示す情報を装置構成と対応付けて保持する保持部から、前記取得した装置構成に対応する実行順序を示す情報を取得する、
処理を実行させることを特徴とする、付記６〜付記８のいずれか１項記載の更新時間推定プログラム。

（付記１０）
前記更新時間を示す情報には、更新前のソフトウェアの版数ごとに更新時間が設定され、
前記コンピュータに、
一の対象装置から当該一の対象装置に係る更新前のソフトウェアの版数を示す情報を取得し、
前記取得した情報が示す版数に対応する更新時間を、前記更新時間を示す情報から抽出し、
前記抽出した更新時間を用いて前記推定を行なう、
処理を実行させることを特徴とする、付記６〜付記９のいずれか１項記載の更新時間推定プログラム。

（付記１１）
ソフトウェアの更新処理が行なわれるモジュールを複数含む対象装置を管理する情報処理装置における更新時間推定方法であって、
前記情報処理装置が、
ソフトウェアの更新処理が行なわれるモジュールを複数含む対象装置に対応した、前記複数のモジュールに係る複数の更新処理の実行順序を示す情報に基づき、前記複数の更新処理から、並行して実行される複数の更新処理を一処理ブロックとした一以上の第１処理ブロックを特定し、
前記複数の更新処理の各々にかかる更新時間を示す情報を用いて、前記特定した第１処理ブロックごとの更新時間を推定し、
更新時間を示す情報及び前記推定した第１処理ブロックごとの更新時間の少なくとも一方に基づいて、前記対象装置の更新時間を推定する、
ことを特徴とする、更新時間推定方法。

（付記１２）
前記情報処理装置が、
前記更新時間を示す情報を用いて、前記特定した第１処理ブロックにおいて並行して更新処理が実行されるルートごとの更新時間を推定し、ルートごとに推定した更新時間のうちの最長の更新時間を当該第１処理ブロックの更新時間として推定する、
ことを特徴とする、付記１１記載の更新時間推定方法。

（付記１３）
前記情報処理装置が、
前記実行順序を示す情報に基づき、前記複数の更新処理から、シーケンシャルに実行される一以上の更新処理を一処理ブロックとした一以上の第２処理ブロックを特定し、
前記更新時間を示す情報を用いて、前記特定した第２処理ブロックにおける更新処理の更新時間を合計し、合計した更新時間を当該第２処理ブロックの更新時間と推定し、
前記推定した第１処理ブロックごとの更新時間及び第２処理ブロックごとの更新時間を合計することで、前記対象装置の更新時間を推定する、
ことを特徴とする、付記１２記載の更新時間推定方法。

（付記１４）
前記情報処理装置が、
一の対象装置から当該一の対象装置の装置構成を示す情報を取得し、
互いに装置構成の異なる複数の対象装置について、各対象装置が含む複数のモジュールに係る複数の更新処理の実行順序を示す情報を装置構成と対応付けて保持する保持部から、前記取得した装置構成に対応する実行順序を示す情報を取得する、
ことを特徴とする、付記１１〜付記１３のいずれか１項記載の更新時間推定方法。

（付記１５）
前記更新時間を示す情報には、更新前のソフトウェアの版数ごとに更新時間が設定され、
前記情報処理装置が、
一の対象装置から当該一の対象装置に係る更新前のソフトウェアの版数を示す情報を取得し、
前記取得した情報が示す版数に対応する更新時間を、前記更新時間を示す情報から抽出し、
前記抽出した更新時間を用いて前記推定を行なう、
ことを特徴とする、付記１１〜付記１４のいずれか１項記載の更新時間推定方法。

１，１−１〜１−ｎ 対象装置
１ａ 仮想テープライブラリ装置（複合システム）
２ 情報処理装置
２ａ 運用コンソール（管理サーバ）
３ ホストサーバ
４ 制御システム
５ａ〜５ｄ，７ａ〜７ｄ，１１ａ，１１ｂ 制御装置
６ａ，６ｂ ＦＣスイッチ
８ ＲＡＩＤ装置
９ａ，９ｂ テープライブラリ装置
１０ａ，１０ｂ ＬＡＮハブ
１２ａ，１２ｂ ライブラリ制御装置
１３ａ，１３ｂ 電源制御装置
２１ 保持部
２２，２２−１〜２２−ｎ アップデートフローデータベース
２３ ファームアップ時間推定部
２４ ＤＢ選択部
２５ ブロック分割部
２６ 推定時間選択部
２７ 第１算出部
２８ 第２算出部
２９ ファームウェア更新処理部
３０ 更新ファームセット
３１ ファームウェアデータ
３２ ファームアップ時間データベース
１００，１００−１〜１００−ｍ，１００ａ モジュール

Claims (7)

1. ソフトウェアの更新処理が行なわれるモジュールを複数含む対象装置に対応した、前記複数のモジュールに係る複数の更新処理の実行順序を示す情報に基づき、前記複数の更新処理から、並行して実行される複数の更新処理を一処理ブロックとした一以上の第１処理ブロックを特定する特定部と、
   前記複数の更新処理の各々にかかる更新時間を示す情報を用いて、前記特定部が特定した第１処理ブロックごとの更新時間を推定する第１推定部と、
   更新時間を示す情報及び前記第１推定部が推定した第１処理ブロックごとの更新時間の少なくとも一方に基づいて、前記対象装置の更新時間を推定する第２推定部と、をそなえる
   ことを特徴とする、情報処理装置。
2. 前記第１推定部は、前記更新時間を示す情報を用いて、前記特定部が特定した第１処理ブロックにおいて並行して更新処理が実行されるルートごとの更新時間を推定し、ルートごとに推定した更新時間のうちの最長の更新時間を当該第１処理ブロックの更新時間として推定する、
   ことを特徴とする、請求項１記載の情報処理装置。
3. 前記特定部は、前記実行順序を示す情報に基づき、前記複数の更新処理から、シーケンシャルに実行される一以上の更新処理を一処理ブロックとした一以上の第２処理ブロックを特定し、
   前記第１推定部は、前記更新時間を示す情報を用いて、前記特定部が特定した第２処理ブロックにおける更新処理の更新時間を合計し、合計した更新時間を当該第２処理ブロックの更新時間と推定し、
   前記第２推定部は、前記第１推定部が推定した第１処理ブロックごとの更新時間及び第２処理ブロックごとの更新時間を合計することで、前記対象装置の更新時間を推定する、
   ことを特徴とする、請求項２記載の情報処理装置。
4. 互いに装置構成の異なる複数の対象装置について、各対象装置が含む複数のモジュールに係る複数の更新処理の実行順序を示す情報を、装置構成と対応付けて保持する保持部と、
   一の対象装置から当該一の対象装置の装置構成を示す情報を取得し、取得した装置構成に対応する実行順序を示す情報を前記保持部から取得する取得部と、をさらにそなえる
   ことを特徴とする、請求項１〜請求項３のいずれか１項記載の情報処理装置。
5. 前記更新時間を示す情報には、更新前のソフトウェアの版数ごとに更新時間が設定され、
   前記第１推定部は、一の対象装置から当該一の対象装置に係る更新前のソフトウェアの版数を示す情報を取得し、取得した情報が示す版数に対応する更新時間を、前記更新時間を示す情報から抽出し、抽出した更新時間を用いて前記推定を行なう、
   ことを特徴とする、請求項１〜請求項４のいずれか１項記載の情報処理装置。
6. コンピュータに、
   ソフトウェアの更新処理が行なわれるモジュールを複数含む対象装置に対応した、前記複数のモジュールに係る複数の更新処理の実行順序を示す情報に基づき、前記複数の更新処理から、並行して実行される複数の更新処理を一処理ブロックとした一以上の第１処理ブロックを特定し、
   前記複数の更新処理の各々にかかる更新時間を示す情報を用いて、前記特定した第１処理ブロックごとの更新時間を推定し、
   更新時間を示す情報及び前記推定した第１処理ブロックごとの更新時間の少なくとも一方に基づいて、前記対象装置の更新時間を推定する、
   処理を実行させることを特徴とする、更新時間推定プログラム。
7. ソフトウェアの更新処理が行なわれるモジュールを複数含む対象装置を管理する情報処理装置における更新時間推定方法であって、
   前記情報処理装置が、
   ソフトウェアの更新処理が行なわれるモジュールを複数含む対象装置に対応した、前記複数のモジュールに係る複数の更新処理の実行順序を示す情報に基づき、前記複数の更新処理から、並行して実行される複数の更新処理を一処理ブロックとした一以上の第１処理ブロックを特定し、
   前記複数の更新処理の各々にかかる更新時間を示す情報を用いて、前記特定した第１処理ブロックごとの更新時間を推定し、
   更新時間を示す情報及び前記推定した第１処理ブロックごとの更新時間の少なくとも一方に基づいて、前記対象装置の更新時間を推定する、
   ことを特徴とする、更新時間推定方法。

Images