WO2014061199A1

WO2014061199A1 - システム設計方法、システム設計装置及びシステム設計プログラム

Info

Publication number: WO2014061199A1
Application number: PCT/JP2013/005471
Authority: WO
Inventors: 紅美子但野
Original assignee: 日本電気株式会社
Priority date: 2012-10-17
Filing date: 2013-09-17
Publication date: 2014-04-24
Also published as: US9740575B2; US20150301908A1; JPWO2014061199A1

Abstract

　システム設計方法、システム設計システム及びシステム設計改善支援用プログラムを提供する。　システム設計装置は、システムの障害復旧手順を表す解析モデルを受け付ける手段と、受け付けた解析モデルから、復旧時間または所要コストの要件を満たさないコンポーネント障害の最小の組合せを特定する手段と、特定したコンポーネント障害の最小の組合せを出力する手段と、を備え、コンポーネント障害の最小の組合せを特定する手段は、システムの復旧時間を推定する手段と、システムの復旧に要するコストを推定する手段と、を有する。

Description

システム設計方法、システム設計装置及びシステム設計プログラム

本発明は、情報処理システムに発生した障害から復旧するための技術に関する。

　大規模災害の発生時には、情報システム中の多くのコンポーネントに同時に障害が発生する可能性がある（以下、コンポーネントに発生する障害をコンポーネント障害と呼ぶことがある。）。このような災害復旧のためのシステム設計においては、システム設計者は、復旧時間の要件を満たすように、コンポーネントに同時に発生する障害からシステムを復旧するための運用手順（障害復旧手順）を設計する。このような障害復旧手順の設計においては、以下の２点を考慮する必要がある。

　第１に、多数のコンポーネントに同時に発生し得る障害の組合せの数は、膨大であることである。このため、すべてのコンポーネント障害の組み合わせを、実環境におけるテストによって評価することは、現実的ではない。この問題に対応するためには、対象となるシステムにおいて測定された基本的なパラメータの値のみを利用して、モデルに基づき障害復旧手順の設計を評価する、モデルベースのアプローチを利用できる。

　第２に、限られた予算の中で、復旧時間に対する顧客要件を充足する必要があることである。例えば、システムの障害復旧について、予め顧客との間で取り決められた契約に基づいて、所定の復旧時間を保証している場合がある。一方、障害復旧時間を短くするための対策には、コストがかかる。例えば、システム構成の観点から、ホットスタンバイなどによるコンポーネントの冗長化などを行うと、設備費が上昇する。他の例として、人的資源の観点から、優秀なシステム管理者を配置すると、人件費が上昇する。このことから、全てのコンポーネント障害の組合せに対して復旧時間の要件を満たすシステムを設計すると、コストが過大となる。しかしながら、復旧時間の要件を満たすべきコンポーネント障害の組合せを、コスト効率的に選ぶ方法は自明ではない。ここで、コスト効率性の観点からは、最も少ない数のコンポーネント障害により、復旧時間または所要コストの要件を満たさなくなるコンポーネント障害の組合せを、システム設計改善の対象とすることが望ましい。

　システム設計上の脆弱な個所を知るために、例えば、システムの障害を表す故障木における、最小カットセット（ＭＣＳｓ；Ｍｉｎｉｍａｌ　Ｃｕｔ　Ｓｅｔｓ）を特定する手法が知られている。ＭＣＳｓは、望ましくないトップ事象（例えば、システム障害）を引き起こしうる、基本事象（例えば、コンポーネント障害）の最小の組み合わせである。

　特許文献１には、故障木のＭＣＳｓを効率的に評価する方法の例が開示されている。特許文献１に開示された技術によれば、多数決ゲートを含む故障木の信頼性分析において、計算量を削減し、かつ、可読性を向上することができる。

　なお、本願の出願人は、特許文献２において、特定の運用手順に従って複数の操作が実行された場合の、情報システムの可用性を推定する可用性モデルを生成する技術について開示している。

特開２０１２－１１３５８２号公報国際公開第２０１２／０５６６１１号

　しかしながら、特許文献１に開示されているような故障木解析は、システムの障害復旧手順のように、対象となるシステムの状態間に複雑な依存関係がある場合には、適用が困難であるという問題がある。複雑な依存関係とは、具体的には、障害復旧手順中の復旧操作の実施によるシステムの状態の変化、当該システムの状態の変化に伴う、実施すべき復旧操作の動的な変化、及び復旧操作の実行順序の制約などである。このため、特許文献１に開示された、故障木のＭＣＳｓに対する評価技術を、本願発明の目的に適用することは困難である。

　本発明は、前述の課題に鑑みてなされたものであり、復旧時間または所要コストの要件を充足しない、コンポーネント障害の最小の組合せを特定するシステム設計装置、システム設計方法、及びシステム設計プログラムを提供することを目的の一つとする。

　上記目的を達成するための本発明の一形態である、システム設計装置は、システムの障害復旧手順を表す解析モデルを受け付ける手段と、受け付けた解析モデルから、復旧時間または所要コストの要件を満たさないコンポーネント障害の最小の組合せを特定する手段と、特定したコンポーネント障害の最小の組合せを出力する手段と、を備え、上記コンポーネント障害の最小の組合せを特定する手段は、システムの復旧時間を推定する手段と、システムの復旧に要するコストを推定する手段と、を有する。

　また、本発明の他の形態であるシステム設計方法は、システムの障害復旧手順を表す解析モデルを受け付け、受け付けた解析モデルから、復旧時間または所要コストの要件を満たさないコンポーネント障害の最小の組合せを特定し、特定したコンポーネント障害の最小の組合せを出力する、システム設計方法であって、上記コンポーネント障害の最小の組合せを特定する際に、上記システムの復旧時間を推定し、上記システムの復旧に要するコストを推定する。

　また、本発明の他の形態であるシステム設計プログラムは、情報処理装置に、システムの障害復旧手順を表す解析モデルを受け付ける手段と、受け付けた解析モデルから、復旧時間または所要コストの要件を満たさないコンポーネント障害の最小の組合せを特定する手段と、特定したコンポーネント障害の最小の組合せを出力する手段と、を実現させるためのプログラムであって、上記コンポーネント障害の最小の組合せを特定する手段は、上記システムの復旧時間を推定する手段と、上記システムの復旧に要するコストを推定する手段を実現するプログラムにより構成される。

　本発明によれば、復旧時間または所要コストの要件を満たさないコンポーネント障害の最小の組合せを特定する、システム設計装置、システム設計方法、及びシステム設計プログラムを提供することができる。

本発明の第１の実施形態に係る、システム設計装置一例を表すブロック図である。本発明の第１の実施形態に係る、システム設計装置の作動を表すフローチャート図である。本発明の第２の実施形態に係る、システム設計装置の一例を表すブロック図である。本発明の第２の実施形態に係る、システム設計装置の作動を表すフローチャートである。本発明の第２の実施形態に係る、障害復旧手順の要素と解析モデルの要素の変換規則の一例を示した図である。本発明の第２の実施形態に係る、障害復旧手順の要素と解析モデルの要素の変換規則の一例を示した図である。本発明の第２の実施形態に係る、障害復旧手順情報を表すアクティビティ図の一例を示した図である。本発明の第２の実施形態に係る、障害復旧手順から生成された解析モデルの一部である、制御フローモデルの一例を示した図である。本発明の第２の実施形態に係る、障害復旧手順から生成された解析モデルの一部である、復旧操作モデルの一例を示した図である。本発明の第２の実施形態に係る、障害復旧手順から生成された解析モデルの一部である、システム状態モデルの一例を示した図である。本発明の第３の実施形態に係る、システム設計装置の概略を表すブロック図である。本発明の第３の実施形態に係る、ステム設計装置の作動の概要を表すフローチャートである。本発明の第２の実施形態における、ＩｎｉｔｉａｌＮｏｄｅ　ｍｏｄｕｌｅに対応するアクティビティ図の構成要素を示した表記例である。本発明の第２の実施形態における、ＩｎｉｔｉａｌＮｏｄｅ　ｍｏｄｕｌｅに対応するＳｔｏｃｈａｓｔｉｃ　Ｒｅｗａｒｄ　Ｎｅｔｓ（ＳＲＮ）モデルモジュールの制御フローモデルを構成する、構成要素の表記例である。本発明の第２の実施形態における、ＤｅｃｉｓｉｏｎＮｏｄｅ　ｍｏｄｕｌｅに対応するアクティビティ図の構成要素を示した表記例である。本発明の第２の実施形態における、ＤｅｃｉｓｉｏｎＮｏｄｅ　ｍｏｄｕｌｅに対応するＳＲＮモデルモジュールの制御フローモデルを構成する、構成要素の表記例である。本発明の第２の実施形態における、ＤｅｃｉｓｉｏｎＮｏｄｅ　ｍｏｄｕｌｅに対応するＳＲＮモデルモジュールのシステム状態モデルを構成する、構成要素の表記例である。本発明の第２の実施形態における、Ａｃｔｉｏｎ　ｍｏｄｕｌｅに対応するアクティビティ図の構成要素を示した表記例である。本発明の第２の実施形態における、Ａｃｔｉｏｎ　ｍｏｄｕｌｅに対応するＳＲＮモデルモジュールの制御フローモデルを構成する、構成要素の表記例である。本発明の第２の実施形態における、Ａｃｔｉｏｎ　ｍｏｄｕｌｅに対応するＳＲＮモデルモジュールの操作復旧モデルを構成する、構成要素の表記例である。本発明の第２の実施形態における、ＦｌｏｗＦｉｎａｌ　ｍｏｄｕｌｅに対応するアクティビティ図の構成要素を示した表記例である。本発明の第２の実施形態における、Ｆｌｏｗ　ｍｏｄｕｌｅに対応するＳＲＮモデルモジュールの制御フローモデルを構成する、構成要素の表記例である。本発明の第２の実施形態における、ＡｃｔｉｖｉｔｙＦｉｎａｌ　ｍｏｄｕｌｅに対応するアクティビティ図の構成要素を示した表記例である。本発明の第２の実施形態における、ＡｃｔｉｖｉｔｙＦｉｎａｌ　ｍｏｄｕｌｅに対応するＳＲＮモデルモジュールの制御フローモデルを構成する、構成要素の表記例である。本発明の第２の実施形態における、”Ｃｏｎｔｒｏｌ　ｗｉｔｈ　ｃｏｎｄｉｔｉｏｎ　ｍｏｄｕｌｅ　Ｉ”に対応するアクティビティ図の構成要素を示した表記例である。本発明の第２の実施形態における、”Ｃｏｎｔｒｏｌ　ｗｉｔｈ　ｃｏｎｄｉｔｉｏｎ　ｍｏｄｕｌｅ　Ｉ”に対応するＳＲＮモデルモジュールのシステム状態モデルを構成する、構成要素の表記例である。本発明の第２の実施形態における、”Ｃｏｎｔｒｏｌ　ｗｉｔｈ　ｃｏｎｄｉｔｉｏｎ　ｍｏｄｕｌｅ　ＩＩ”に対応するアクティビティ図の構成要素を示した表記例である。本発明の第２の実施形態における、”Ｃｏｎｔｒｏｌ　ｗｉｔｈ　ｃｏｎｄｉｔｉｏｎ　ｍｏｄｕｌｅ　ＩＩ”に対応するＳＲＮモデルモジュールのシステム状態モデルを構成する、構成要素の表記例である。本発明の第２の実施形態における、Ｐｒｉｏｒ　ｍｏｄｕｌｅに対応するアクティビティ図の構成要素を示した表記例である。本発明の第２の実施形態における、Ｐｒｉｏｒ　ｍｏｄｕｌｅに対応するＳＲＮモデルモジュールのシステム状態モデルを構成する、構成要素の表記例である。本発明の第１の実施形態に係る、システム設計装置のハードウェア構成図である。

　この出願は、２０１２年１０月１７日に出願された日本出願特願２０１２－２３００３９を基礎とする優先権を主張し、その開示の全てをここに取り込む。そして、本国際出願では、説明の便宜上から、係る日本出願の図面の表現を、国際出願の規定を満足すべく複数の図面に展開することとする。これに応じて、本出願人は、以降に説明する各実施形態の説明も、調整後の図面に応じた記載に調整することとする。これらの処置は、言語の違いに起因する、各国移行時の言語変換への配慮であり、何ら新規事項を含む処置ではない。

　以下、本発明に係る、システム設計装置、システム設計方法、及びシステム設計プログラム、の各実施形態について図１乃至図３０を参照しながら説明する。各図において対応する部分には同一符号を付し、かかる部分の重複する説明は省略する。

　（用語について）
　まず、以下に説明する各実施形態における、障害復旧手順について説明する。以下の実施形態において、障害復旧手順は、障害の発生したコンポーネントを復旧するための手順である。障害復旧手順は、システムに含まれるコンポーネントの一部を復旧するサブ手順から構成される。各サブ手順は、リプレース、再起動、データ復旧、設定変更などのシステム管理操作を含む。各サブ手順は、復旧の対象となるコンポーネントに応じて予めドキュメントやマニュアルなどに記述される。

　災害等によって複数のコンポーネント障害が同時に発生した場合、システムオペレータは障害復旧手順に従ってコンポーネントを復旧する責任を担う。障害が発生したコンポーネントの組み合わせに依存して、必要なサブ手順は異なる。そこで、システムオペレータは、最初にシステムにおいて発生した障害を正確に把握し（すなわち、障害の発生したコンポーネントを識別し）、次にシステム復旧のために実行すべきサブ手順を決定する。本稿におけるコンポーネントの障害状態には、コンポーネントのダウン（使用不能）だけでなく、「必須のコマンドの一部が実行できない」、「システムに必要なデータの一部が消失している」といった、コンポーネントを正常に利用できない状態も含まれる。これらの異なる種類の障害状態に応じて、障害復旧手順に含まれる必要なサブ手順は異なる。

　次に、本願発明の各実施形態における、許容できないコンポーネント障害の最小の組合せ（以下、「障害の最小の組合せ」あるいは「最小の組合せ」と称することがある。）について説明する。本願発明の各実施形態において、障害の最小の組合せとは、復旧時間または障害復旧に要する総コストの要件を満たさなくなる、同時発生したコンポーネント障害の最小の組み合わせである。

　以下に、例をあげる。ここでは、システム中に４つのコンポーネントＡ，Ｂ，Ｃ，Ｄが存在する場合を想定する。これらのコンポーネントの障害を、それぞれＦＡ，　ＦＢ，　ＦＣ，　ＦＤと表す。このシステムの復旧時間の要件　を、ｔ_ｒｅｑと表す。例えば、コンポーネント障害が同時に発生した際に、復旧時間がｔ_ｒｅｑを超えるのは、コンポーネント障害の組み合わせが｛ＦＡ，　ＦＢ｝、　｛　ＦＡ，　ＦＢ，　ＦＣ｝、｛　ＦＡ，　ＦＢ，　ＦＤ｝、｛　ＦＡ，　ＦＢ，　ＦＣ，　ＦＤ｝の場合であるとする。この場合、コンポーネントの障害の組み合わせ｛ＦＡ，　ＦＢ｝が最小の組合せである。なぜならば、｛ＦＡ，　ＦＢ｝のコンポーネント障害数が、上にあげた４つの組み合わせの中でもっとも小さいからである。残りの３つの組み合わせの復旧時間の値は、必ず｛ＦＡ，　ＦＢ｝の復旧時間の値より大きくなる。

　＜第１の実施形態＞
　図１に示したように、第１の実施形態に係るシステム設計装置１の機能は情報処理装置によって実現される
　　（構成）
　システム設計装置１は、例えば、サーバ装置、又は、パーソナル・コンピュータ等のコンピュータシステムによって構成される。

　システム設計装置１は、図３０に示す中央処理装置３００１（ＣＰＵ；Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）、記憶装置３００２（メモリ及びハードディスク駆動装置（ＨＤＤ；Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ））、入力装置３００３（本実施形態においては、キーボード）、及び、出力装置３００４（本実施形態においては、ディスプレイ）等を備える。システム設計装置１は、記憶装置に記憶されているプログラムをＣＰＵが実行することにより、後述する機能を実現するように構成してもよい。なお、当該プログラムは記憶媒体３００６に記憶され、外部記憶装置３００５により読み込まれるように構成してもよい。

　（機能）
　図１は、システム設計装置１の機能を表すブロック図である。システム設計１の機能は、解析モデル受付部（解析モデル受付手段）１００と、最小組合せ特定部（最小組合せ特定手段）１０４と、要件受け付け部１０５と、最小組合せ出力部（最小組合せ特定手段）１０６と、を含んでいる。また、最小組合せ出力部１０４は、復旧時間推定部（復旧時間推定手段）１０７と、コスト推定部（コスト推定手段）１０８と、を含んでいる。

　解析モデル受付部１００は、障害復旧手順の設計に基づき障害復旧時間を評価する、解析モデルを受け付ける。本実施形態においては、解析モデルは、システムのどの部分（コンポーネント）に障害が発生し、どの部分は正常稼働中であるといった、現在のシステムの状態と、各復旧操作の実行に要する時間や成功率といった特徴を表すパラメータと、障害復旧手順中の各復旧操作の実行によるシステムのすくなくとも一部の状態の変化と、上記システムの一部の状態の変化に伴う実行すべき復旧操作の変化および復旧操作の実行順序の制約を表現する障害復旧手順の制御フローと、を表すモデルである。さらに、本実施形態においては、解析モデルは、特定の確率分布に基づいて状態遷移が起こる、状態遷移モデルである。本実施形態においては、このような状態遷移モデルとして、例えば、Ｓｔｏｃｈａｓｔｉｃ　Ｒｅｗａｒｄ　Ｎｅｔｓ（以下ＳＲＮと呼ぶ）モデルを採用する。なお、状態遷移モデルは適宜選択してよく、本実施形態においても、ＳＲＮモデルに限定されず、別の状態遷移モデルを採用してもよい。

　要件受け付け部１０５は、システム設計者等が入力装置等によって予め入力した復旧時間とコストの要件を受け付けて記憶している。

　最小組合せ特定部１０４は、各コンポーネント障害の組合せについて、復旧時間推定部１０７を用いて復旧時間を推定し、推定した復旧時間からコスト推定部１０８を用いてコストを推定し、推定された復旧時間及びコストから、要件受け付け部１０５にて受け付けた復旧時間またはコストの要件を満たさないコンポーネント障害の最小の組合せを特定する。

　上述した復旧時間推定部１０７は、要件受け付け部１０５において受け付けた解析モデルを各コンポーネント障害の組合せについて解くことで、復旧時間を推定する。例えば、コンポーネントＸ，Ｙの障害を復旧手順Ａに基づき復旧した場合、９９％の確率で５時間以内に復旧するといったように、復旧時間が推定される。

　コスト推定部１０８は、上記復旧時間推定部１０７により推定された復旧時間を基に、特定の算出式を用いてコストを推定する。算出式には、例えば、災害復旧システムを構築するための初期費用や、障害復旧手順実施のための時間当たりの人件費、障害発生時の単位時間当たりのダウンタイムコストなどが含まれる。例えば、コンポーネントＸ，Ｙの障害を復旧手順Ａに基づき復旧した場合、所要コストは１０００万円などといったコストが表示される。

　最小組合せ出力部１０６は、最小組合せ特定部１０４が特定した最小の組合せを提示する。例えば、「｛コンポーネントＡ，コンポーネントＣ，コンポーネントＦ｝と｛コンポーネントＡ，コンポーネントＤ，コンポーネントＧ｝」などとディスプレイ上に提示してもよい。

　　（作動）
　次に、上述したシステム設計装置１の作動について、図２を参照して説明する。

　先ず、システム設計装置１は、システム設計者から、評価対象となる障害復旧手順を表す解析モデル受け付ける（図２に示すステップＳ１０００）。システム設計装置１は、例えば、解析モデルがＳＲＮモデルの場合は、Ｓｔｏｃｈａｓｔｉｃ　Ｐｅｔｒｉ　Ｎｅｔ　Ｐａｃｋａｇｅ（以下ＳＰＮＰと呼ぶ）などの既存の解析ツールの表記法に基づき記載された解析モデルを受け付けてもよい。

　次いで、システム設計装置１は、ステップＳ１０００において受け付けた解析モデルを解くことにより、コンポーネント障害の各組合せ全てについて、復旧時間を推定する（図２に示すステップＳ１０３０）。システム設計装置１は、例えば、受け付けたモデルがＳＲＮモデルの場合は、ＳＰＮＰなどの既存の解析ツールを用いて解析モデルを解く。この場合、例えば、コンポーネント障害の組合せを変更するために、ＳＲＮモデル上のシステムの各部分の状態を表す１つ以上のトークンの初期位置（一般にトークンの初期分布は初期マーキングと呼ばれる）が変更される。復旧時間は、モデル上で「障害復旧手順の開始」を表す状態から、「完全復旧」を表す状態に遷移するまでの時間として計算される。

　次いで、システム設計装置１は、ステップＳ１０３０において推定された復旧時間に基づき、コストを推定する（図２に示すステップＳ１０４０）。推定された復旧時間の値と、コストに関するパラメータの値を利用して、本実施形態において提案するシステム設計装置１は、総コストＣ_{ｔｏｔａｌ}を計算する。例えば、復旧時間をＴＴＲとし、コストに関するパラメータとして、単位時間当たりの障害復旧のための人件費Ｃ_ｒｅｃｖ、復旧操作を実行するシステムオペレータの教育費Ｃ_{ｔｒａｉｎ}、障害復旧手順を実行するのための設備投資Ｃ_{ｉｎｉｔａｌ}、復旧時間の要件を超えた分の時間ｔ_{ｖｉｏｌａｔｉｏｎ}、単位時間当たりのダウンタイムコストＤを用いて、システム設計装置１は、総コストＣ_{ｔｏｔａｌ}を下式により計算する。
Ｃ_{ｔｏｔａｌ}　＝　Ｄ×ｔ_{ｖｉｏｌａｔｉｏｎ}　＋　Ｃ_ｒｅｃｖ×ＴＴＲ　＋　Ｃ_{ｔｒａｉｎ}　＋　Ｃ_{ｉｎｉｔａｌ}
　なお、ステップＳ１０３０においてコンポーネント障害の全組合せについて復旧時間を求めた後、ステップＳ１０４０にてコンポーネント障害の全組合せについてコストを求めたが、コンポーネント障害の一つの組合せごとに復旧時間の推定・コストの推定を繰り返してもよい。

　次いで、システム設計装置１は、システム設計者等からの、復旧時間とコストの要件を受け付ける（図２に示すステップＳ１０５０）。例えば、復旧時間の要件を３時間、総コストの要件を３０００万円のように設定することができる。これらの値は、システムに依存する。

　次いで、システム設計装置１は、ステップＳ１０５０により得られた復旧時間とコストの要件と、ステップ１０３０により得られた復旧時間と、ステップ１０４０により得られたコストと、に基づき、コンポーネント障害の最小の組合せを特定する（図２に示すステップＳ１０６０）。具体的には、ステップS１０５０により得られた要件を満たさないコンポーネント障害の組合せの中で、コンポーネント障害の数が最小となる組合せを、最小の組合せとして特定する。

　次いで、システム設計装置１は、ステップＳ１０６０により得られた最小の組合せを、ディスプレイなどに出力する（図２に示すステップＳ１０７０）。

　　（第１の実施形態による効果）
　上述した本発明の第１の実施形態によれば、情報処理システムにおいて複数のコンポーネントに同時に発生する障害の解析において、当該障害の復旧時間または所要コストの要件を満たさないコンポーネント障害の最小の組み合わせを特定できる。本発明の第１の実施形態に係るシステム設計装置により、システム設計者は、現在の設計の限界を定量的に理解し、障害復旧に関わるシステム設計を効率的に改善できる。また、顧客の要求するシステム障害の復旧要件（復旧時間、コスト等）の充足可能性を容易に判断できる。

　＜第２の実施形態＞
　次に、本発明の第２の実施形態に係るシステム設計装置について、図３を参照して説明する。同図において図１と対応する部分には同一符号を付し、かかる部分の説明は省略する。

　第２の実施形態に係るシステム設計装置は、第１の実施形態に係るシステム設計装置１に対して、障害復旧手順から解析モデルを自動生成する構成を更に有している。以下、かかる構成を中心に説明する。

　　（機能）
　図３は、第２の実施形態に係るシステム設計装置１の機能を表すブロック図である。第２の実施形態に係るシステム設計装置１の機能は、第１の実施形態に係るシステム設計装置１の機能（最小組合せ特定部１０４，要件受付部１０５，最小組合せ出力部１０６）に加えて、障害復旧手順受付部１０１と、解析モデル生成部１０２を含む。また、第２の実施形態に係るシステム設計装置１の機能は、第１の実施形態に係るシステム設計装置１の機能のうち、解析モデル受付部１００を含まなくてもよい。

　障害復旧手順受付部１０１は、システム設計者から、評価対象となる障害復旧手順を受け付ける。システム設計者は、例えば、Ｓｙｓｔｅｍｓ　Ｍｏｄｅｌｉｎｇ　Ｌａｎｇｕａｇｅ（以下ＳｙｓＭＬと呼ぶ）のアクティビティ図を用いて設計した障害復旧手順を入力する。

　解析モデル生成部１０２は、受け付けた障害復旧手順から解析モデルを生成する。例えば、解析モデル生成部１０２は、モデルモジュールのデータベース１０３に予め記憶されているアクティビティ図とＳＲＮの間の事前定義された変換規則に基づき、アクティビティ図をＳＲＮ形式の解析モデルに変換する。その他の構成は図１に示す本発明の第１の実施形態に係る構成と同様である。

　　（作動）
　次に、上述したシステム設計装置１の作動について、図４を参照して説明する。図４は、本発明の第２の実施形態に係るシステム設計装置の作動の概要を表すフローチャートである。

　まず、本実施形態に係るシステム設計装置は、システム設計者から障害復旧手順を受け付ける（図４に示すステップＳ１０１０）。本実施形態においては、例えば、システム設計者は、アクティビティ図を利用して、障害復旧手順を記述する。図５A、図５B及び図１２乃至図２９に、アクティビティ図の表記例を示し、図６に障害復旧手順を表すアクティビティ図の一例を示す。なお、図５A及び図５Bの表中に、モデルの構成要素に対する参照番号と、当該参照番号に対応するモデルの構成要素を表記した図面番号を記載している。

　本実施形態においては、障害復旧手順の特徴を表すために、５種類のノードを用いる。以下、それぞれのノードについて説明する。

　＜Ａｃｔｉｏｎ＞：長方形で表されるＡｃｔｉｏｎは、障害復旧手順の一つの操作（例えば、リプレースや、再起動や、データ復旧等）を表す。（図５Aに示す参照番号５A-F17（図１７に示す１７０１）及び、図６に示す６０１、６０２等）
　＜ＤｅｃｉｓｉｏｎＮｏｄｅ＞：菱形で表されるＤｅｃｉｓｉｏｎＮｏｄｅは、その出力（ｙｅｓまたはｎｏ）が特定のシステムコンポーネントの状態（例えば、コンポーネントが正常稼働中または故障中である、バックアップファイルが存在しているまたはしていない等）に応じて決定される条件分岐を表す（図５Aに示す参照番号５Ａ-Ｆ１４（図１４に示す１４０１）、図６に示すｄ_１、ｄ_２、ｄ_３等）。解析モデルの合成に必要な情報として、システム設計者はｙｅｓまたはｎｏのどちらの出力がコンポーネントの故障状態に相当するかを決定する。コンポーネントの状態は、特定の復旧操作の実行が成功すると、変化する。ただし、復旧不能な障害も存在するため、このような復旧操作は、常に存在するとは限らない。

　＜ＩｎｉｔｉａｌＮｏｄｅ＞：円形（黒丸）で表されるＩｎｉｔｉａｌＮｏｄｅは、障害復旧手順の制御フローの開始点を表す（図５Ａに示す参照番号５Ａ－Ｆ１２（図１２における１２０１）及び図６に示す６０３）。

　＜ＡｃｔｉｖｉｔｙＦｉｎａｌ＞：内部に黒点のある円形で表されるＡｃｔｉｖｉｔｙＦｉｎａｌは、システムが完全に復旧した状態（例えば、故障したデータベースサーバをデータが最新の状態で復旧した場合等）における、制御フローの終了点を表す（図５Ｂに示す参照番号５Ｂ－Ｆ２２（図２２における２２０１）及び図６に示す６０４）。

　＜ＦｌｏｗＦｉｎａｌ＞：内部に十字のある円形で表されるＦｌｏｗＦｉｎａｌは、システムが部分的に故障したままの状態（例えば、故障したデータベースサーバがデータを破損した状態で復旧した場合等）における、制御フローの終了点を表す（図５Ｂに示す参照番号５Ｂ－Ｆ２０（図２０における２００１）及び図６に示す６０５）。

　一つのＡｃｔｉｏｎ　ｏｐ_ｘに対して、パラメータとして、復旧操作の成功率ｒ_ｘ、　復旧操作の実行時間ｔ_ｒｘ　が定義される（図１７における１７０２、図６における６０６等）。一つの　ＤｅｃｉｓｉｏｎＮｏｄｅ　ｄ_θに対して、パラメータとして、状態のチェックが完了するまでの時間ｔ_ｃθ　が定義される（図１４における１４０２）。これらのパラメータの値はノードに関連づけられたｎｏｔｅに指定され、合成されたＳＲＮモデルの遷移率（遷移確率）として利用される。

　各復旧操作の対象システムコンポーネントは、ＳｙｓＭＬのａｌｌｏｃａｔｉｏｎを利用して指定される。ＳｙｓＭＬのａｌｌｏｃａｔｉｏｎは、ＡｃｔｉｏｎやＤｅｃｉｓｉｏｎＮｏｄｅ等のＳｙｓＭＬ要素間の様々な関係を表す。本実施形態においては、障害復旧手順の関係を表すために、ＡｃｔｉｏｎとＤｅｃｉｓｉｏｎＮｏｄｅ　の間のａｌｌｏｃａｔｉｏｎについて、以下２つのｓｔｅｒｅｏｔｙｐｅを定義する。

　＜ｃｏｎｔｒｏｌ　ｗｉｔｈ　ｃｏｎｄｉｔｉｏｎ＞：このｓｔｅｒｅｏｔｙｐｅを持つ、ある操作ｏｐ_ｘを表すＡｃｔｉｏｎから、ある条件分岐ｄ_θを表すＤｅｃｉｓｉｏｎＮｏｄｅへのａｌｌｏｃａｔｉｏｎは、ｏｐ_ｘの実行の成功が、ｄ_θの出力を変えることを意味する（図５Ｂに示す参照番号５Ｂ－Ｆ２４（図２４における２４０１）、図６に示す６０９等）。あるＡｃｔｉｏｎの実行の成功による、ＤｅｃｉｓｉｏｎＮｏｄｅの出力の変化の内容は、ａｌｌｏｃａｔｉｏｎに関連したｎｏｔｅに条件として記述される（図２４における２４０２、図６に示す６１０等）。一方、このｓｔｅｒｅｏｔｙｐｅを持つ、ＤｅｃｉｓｉｏｎＮｏｄｅ　ｄ_Ψから、ＤｅｃｉｓｉｏｎＮｏｄｅ　ｄ_θへのａｌｌｏｃａｔｉｏｎは、ｄ_θの出力はｄ_Ψの出力に従って変化することを意味する（図５Ｂに示す参照番号５Ｂ－Ｆ２６（図２６における２６０１））。同様に、ｄ_Ψによる変化の内容は、Ａｌｌｏｃａｔｉｏｎに関連したｎｏｔｅに条件として記述される（図２６の２６０２）。なお、このallocationは、本願図面においては、＜＜ｃｏｎｔｒｏｌ＞＞と表記されることがある。

　＜ｐｒｉｏｒ＞：障害復旧手順操作には、実行順序に依存関係がある場合がある。例えば、障害から復旧するためには、特定の操作が成功する前に、別の特定の操作が成功している必要がある場合が該当する。システム設計者がこれらの依存関係の制約を明確に記述できるよう、本実施形態においては、このような依存関係を表現するｓｔｅｒｅｏｔｙｐｅとして、＜ｐｒｉｏｒ＞を導入する。二つの操作ｏｐ_ｘ　、ｏｐ_ｙを表す２つのＡｃｔｉｏｎから、一つのＤｅｃｉｓｉｏｎＮｏｄｅ　ｄ_θへ＜ｃｏｎｔｒｏｌ　ｗｉｔｈ　ｃｏｎｄｉｔｉｏｎ＞というｓｔｅｒｅｏｐｔｙｐｅを持つ二つのａｌｌｏｃａｔｉｏｎがある場合、ｏｐ_ｘからｏｐ_ｙへのｐｒｉｏｒというｓｔｅｒｅｏｔｙｐｅを持つａｌｌｏｃａｔｉｏｎは、ｄ_θの出力を変化させるためにはｏｐ_ｙの実行の成功の前にｏｐ_ｘの実行の成功が必要であることを意味する（図５Ｂに参照番号５Ｂ－Ｆ２８（図２８における示す２８０１））。なお、このallocationは、本願図面においては、＜＜ｐｒｉｏｒ＞＞と表記されることがある。

　次いで、ステップＳ１０１０において受け付けた障害復旧手順から解析モデルを生成する（図４に示すステップＳ１０２０）。本実施形態においては、解析モデルは、ＳＲＮモデルを用いて表現される。

　例えば、図５（図５Ａ及び図５Ｂ）に示すように、ステップＳ１０２０において生成されたＳＲＮモデルは、１つ以上のシステム状態モデル、１つの制御フローモデル、１つ以上の復旧操作モデルの三種類のサブモデルから構成される。制御フローモデルは、入力された障害復旧手順の制御フローを表す。各復旧操作モデルは、一つの復旧操作を表す。各システム状態モデルは、対象システムの一部の状態（正常に稼働中または故障中）を表す。

　本実施形態においては、解析モデル生成部１０２は、アクティビティ図の部品（以下ＡＤモジュールという）とＳＲＮモデルの部品（以下ＳＲＮモデルモジュールという）の間の変換規則に基づき、以下の３つのサブステップに従い、ＳＲＮモデルを合成する。なお、図５Ａ及び図５Ｂには、障害復旧手順の要素と解析モデルの要素の変換規則の一例が表される。

　解析モデル生成部１０２は、サブステップ１において、受け付けたアクティビティ図を、ＡＤモジュールに分割する。解析モデル生成部１０２は、サブステップ２において、ＡＤモジュールをＳＲＮモデルモジュールに変換する。解析モデル生成部１０２は、サブステップ３において、変換されたＳＲＮモデルモジュールを、一つのＳＲＮモデルに統合する。以下、ぞれぞれのサブステップについて説明する。

　サブステップ１：サブステップ１において、解析モデル生成部１０２は、入力されたアクティビティ図を、図５Ａ及び図５Ｂに示す表の第３列に示すように、ノードと出力エッジで構成されるＡＤモジュールに分割する。ＡＤモジュールの各ノードに入力されるエッジは、一つ前のＡＤモジュールからの出力エッジを表す（図１４における１４０３、図１７における１７０３等）。図５ＢにおけるＡＤモジュール（ｆ）”Ｃｏｎｔｒｏｌ　ｗｉｔｈ　Ｃｏｎｄｉｔｉｏｎ　ｍｏｄｕｌｅ　Ｉ”、（ｇ）”Ｃｏｎｔｒｏｌ　ｗｉｔｈ　Ｃｏｎｄｉｔｉｏｎ　ｍｏｄｕｌｅ　ＩＩ”、（ｈ）Ｐｒｉｏｒ　Ｍｏｄｕｌｅにおけるノード間のエッジは、前述したａｌｌｏｃａｔｉｏｎを表す。図５ＡにおけるＡＤモジュール（ａ）ＩｎｉｔｉａｌＮｏｄｅ　ｍｏｄｕｌｅ、（ｂ）ＤｅｃｉｓｉｏｎＮｏｄｅ　ｍｏｄｕｌｅ、（ｃ）Ａｃｔｉｏｎ　ｍｏｄｕｌｅ及び、図５Ｂにおける（ｄ）ＦｌｏｗＦｉｎａｌ　ｍｏｄｕｌｅ、（ｅ）ＡｃｔｉｖｉｔｙＦｉｎａｌ　ｍｏｄｕｌｅは、前述したそれぞれのノードと、次のＡＤモジュールへのエッジを含む。図５ＢにおけるＡＤモジュール（ｆ）”Ｃｏｎｔｒｏｌ　ｗｉｔｈ　Ｃｏｎｄｉｔｉｏｎ　ｍｏｄｕｌｅ　Ｉ”、（ｇ）”Ｃｏｎｔｒｏｌ　ｗｉｔｈ　Ｃｏｎｄｉｔｉｏｎ　ｍｏｄｕｌｅ　ＩＩ”、（ｈ）Ｐｒｉｏｒ　Ｍｏｄｕｌｅは、ａｌｌｏｃａｔｉｏｎのみを含む。図５ＡにおけるＡＤモジュール（ａ）ＩｎｉｔｉａｌＮｏｄｅ　ｍｏｄｕｌｅに対する入力エッジの数は、０に固定される。図５ＡにおけるＡＤモジュール（ｂ）ＤｅｃｉｓｉｏｎＮｏｄｅ　ｍｏｄｕｌｅ、（ｃ）Ａｃｔｉｏｎ　ｍｏｄｕｌｅ及び、図５ＢにおけるＡＤモジュール（ｄ）ＦｌｏｗＦｉｎａｌ　ｍｏｄｕｌｅ、（ｅ）ＡｃｔｉｖｉｔｙＦｉｎａｌ　ｍｏｄｕｌｅに対する入力エッジの数は、入力されたアクティビティ図の制御フローに依存する。なお、以下においては、図５Ａ及び図５Ｂにおいて示す各ADモジュールについて、記号（ａ）乃至（ｈ）を用いて参照することがある。

　サブステップ２：サブステップ２において、解析モデル生成部１０２は、前記各ＡＤモジュールを、図５Ａ及び図５Ｂにおける表の４～６列に示すように、対応するＳＲＮモデルモジュールにそれぞれ変換する。

　サブステップ３：サブステップ３において、解析モデル生成部１０２は、変換元のアクティビティ図において表現されたＡＤモジュール間の接続関係に従い、サブステップ２において変換したＳＲＮモデルモジュールを、解析のための一つのＳＲＮモデルに統合する。変換後の各ＳＲＮモデルモジュールの出力アークは、変換元のアクティビティ図において接続先となっている、ＡＤモジュールから変換されたＳＲＮモデルモジュールのプレースに接続される。ここで、プレースは、SRNモデルにおいてシステムがとりうる状態を表す。

　変換元のアクティビティ図において接続先となっているＡＤモジュールが図５Ａおよび５Ｂおける（ｂ）または、（ｃ）または、（ｄ）または、（ｅ）の場合、出力アークはそれぞれプレースＰ_ｐｒｅθ（図５Aの参照番号５Ａ－Ｆ１５、図１５における１５０１）または、Ｐ_{ｅｘｅｃｘ}（図５Ａの参照番号５Ａ－Ｆ１８、図１８における１８０１）または、Ｐ_{ｕｎｒｅｃｖφ}（図５Ｂの参照番号５Ｂ－Ｆ２１、図２１における２１０１）または、Ｐ_ｒｅｃｖ（図５Ｂにおける参照番号５Ｂ－Ｆ２３、図２３における２３０１）に接続される。

　図５Ａおよび図５Ｂにおいて、合成されたモデルのガード関数の名前については、以下の命名規則を採用している。即ち、あるトランジションがガード関数を持つ場合、そのトランジションの名前は自身のガード関数名を下付き文字として持つ（図５Ａ及び図５Ｂにおける表の7列目）。例えば、図５Ａにおける（ｂ）ＤｅｃｉｓｉｏｎＮｏｄｅ　ｍｏｄｕｌｅについて、トランジションｔ_{ｇｙｅｓθ}は、ガード関数ｇ_ｙｅｓθを持つ。各ガード関数の名前は”ｇ”で始まり、その下付き文字は、トークンが存在する時そのガード関数を持つトランジションの発火を可能にするプレースの名前である（図５Ａ及び図５Ｂにおける表の10列目）。ここで、トランジションは、システムにおける状態の遷移を表し、ガード関数は、トランジションが起こる条件を表す。また、トークンが存在するプレースが、システムにおける現在の状態を表す。

　図５Ａ及び図５Ｂに示した、ＡＤモジュールからＳＲＮモデルモジュールへの変換（ａ）～（ｈ）の詳細は、以下の通りである。

　まず、図５Ａに示す（ａ）ＩｎｉｔｉａｌＮｏｄｅモジュールは、一つのＩｎｉｔｉａｌＮｏｄｅ（図５Aの参照番号５Ａ－Ｆ１２（図１２の１２０１））と、一つの出力エッジ（図１２の１２０２）を含む。（ａ）ＩｎｉｔｉａｌＮｏｄｅモジュールは、制御フローモデルの開始のプレースＰ_ｉｎｉｔ（図５Ａの参照番号５Ａ－Ｆ１３（図１３の１３０１）と、そのプレースからの一つの出力エッジ（図１３の１３０２）に変換される。

　次に、図５Ａに示す（ｂ）ＤｅｃｉｓｉｏｎＮｏｄｅモジュールは、一つのＤｅｃｉｓｉｏｎＮｏｄｅ(図１４の１４０１）と、二つの出力エッジを含む（図１４の１４０４）。（ｂ）ＤｅｃｉｓｉｏｎＮｏｄｅ　Ｍｏｄｕｌｅは、下記（１）及び（２）により、ＳＲＮモデルにおける制御フローモデル及びシステム状態モデルに変換される。

　　（１）　ＤｅｃｉｓｉｏｎＮｏｄｅ　Ｍｏｄｕｌｅは、図５Ａの参照番号５Ａ－Ｆ１５（図１５）に示す制御フローモデルのプレース（Ｐ_ｐｒｅθ及びＰ_ｄｅｃθ等）（図１５の１５０１及び１５０２）、トランジション（ｔ_{ｇｙｅｓθ}及びｔ_ｇｎｏθ等）、及びアークに変換される。

　　（２）　ＤｅｃｉｓｉｏｎＮｏｄｅ　Ｍｏｄｕｌｅは図５Ａの参照番号５Ａ－Ｆ１６（図１６）に示すシステム状態モデルの二つのプレース（Ｐ_ｙｅｓθ及びＰ_ｎｏθ）に変換される（図１６の１６０１及び１６０２）。

　まず、上述した（１）における制御フローモデルについて説明する。図5Aに示すＡＤモジュール（ａ）または、（ｂ）または、（ｃ）から変換された一つ前の（遷移元の）ＳＲＮモデルモジュールから、トークンがプレースＰ_ｐｒｅθに移動した場合、トークンは遷移率１／ｔ_１［１／時間］でプレースＰ_ｄｅｃθに移動する。ＤｅｃｉｓｉｏｎＮｏｄｅ　ｄ_θの出力がｙｅｓまたはｎｏの場合、それぞれトランジションｔ_{ｇｙｅｓθ}またはｔ_ｇｎｏθが発火し、トークンが次の（遷移先の）ＡＤモジュールから変換された、ＳＲＮモデルモジュールのプレースに移動する。次に、上述した（２）における、システム状態モデルについて説明する。ＤｅｃｉｓｉｏｎＮｏｄｅ　ｄ_θの２つの出力（ｙｅｓ，ｎｏ）を表すため、変換されたシステム状態モデルは２つの出力に対応する２つのプレースＰ_ｙｅｓθおよびＰ_ｎｏθを持つ(図１６における１６０１及び１６０２）。Ｐ_ｙｅｓθまたはＰ_ｎｏθのいずれかに、１つのトークンが存在する。解析モデル生成部１０２が複数あるコンポーネント障害の組合せについてモデル解析を実行する際に、トークンの初期位置（初期プレース）は、自動的に変化する。これらのプレースの間のトークンの遷移は、図５Bに示したallocation としての（ｆ）または（ｇ）によって決定される。ｄ_１の入力アーク数については、入力アーク数は一つのみの場合は、即時トランジション（ｉｍｍｅｄｉａｔｅ　ｔｒａｎｓｉｔｉｏｎ）　ｔ_ｇ１、時間付トランジション（ｔｉｍｅｄ　ｔｒａｎｓｉｔｉｏｎ）　　Ｔ_ｄｅｃθ、プレースＰ_ｐｒｅθを、遷移率１／ｔ_１を持つ一つの時間付トランジションＴ_ｇ１［１／時間］に統合する。なぜならば、これらの到達可能性グラフ（ｒｅａｃｈａｂｉｌｉｔｙ　ｇｒａｐｈ）は等しいためである。

　図５Ａに示す（ｃ）Ａｃｔｉｏｎ　ｍｏｄｕｌｅは一つのＡｃｔｉｏｎと一つの出力エッジを持つ(図１７における１７０１及び１７０４）。（ｃ）Ａｃｔｉｏｎ　ｍｏｄｕｌｅは、下記（１）及び（２）により、ＳＲＮモデルにおける制御フローモデル及び復旧操作状態モデルに変換される。

　　（１）　Ａｃｔｉｏｎ　ｍｏｄｕｌｅは、制御フローモデルのプレース（Ｐ_{ｅｘｅｃｘ}、Ｐ_{ｒｅｔｕｒｎｘ}等）、トランジション（ｔ_{ｇｆｉｎｉｓｈｘ}、ｔ_{ｇｂｅｆｏｒｅｘ}等）、及びアークに変換される（図５Ａの参照番号５Ａ－Ｆ１８（図１８））。

　　（２）　Ａｃｔｉｏｎ　ｍｏｄｕｌｅは、一つの復旧操作モデルに変換される（図５Ａの参照番号５Ａ－Ｆ１９（図１９））。復旧操作モデル（図１９）において、遷移率Ｔ_{ｇｅｘｅｃｘ}と遷移確率ｔ_{ｓｕｃｃｅｓｓｘ}は、システム設計者によって入力されたパラメータである、復旧操作の成功率ｒ_ｘと、復旧操作の実行時間ｔ_ｒｘの値によって決定される。なお、ｒ_ｘ及びｔ_ｒｘは、変換元ＡＤモジュールに対するｎｏｔｅにて指定される（図１７）。

　変換されたＳＲＮモデルモジュールにおける、制御フローモデルと、復旧操作モデルは、次のように相互作用する。トークンが上述した（１）における制御フローモデルのＰ_{ｅｘｅｃｘ}に移動したとき、上述した（２）における復旧操作モデルにおいて、Ｔ_{ｇｅｘｅｃｘ}が発火可能になる。復旧操作モデルにおいて、Ｐ_{ｂｅｆｏｒｅｘ}のトークンは遷移率１／ｔ_２［１／ｈ］でＰ_{ｂｒａｎｃｈｘ}に移動する。その後、ｔ_{ｓｕｃｃｅｓｓｘ}が発火確率ｐ_１で発火し、トークンがＰ_ｏｐｘを経由してＰ_{ｆｉｎｉｓｈｘ}に移動する。例えば、特定の操作ｏｐ_ｘを表すＡｃｔｉｏｎ　ｍｏｄｕｌｅが、前記ｓｔｅｒｅｏｔｙｐｅとして＜＜ｃｏｎｔｒｏｌ＞＞を持つａｌｌｏｃａｔｉｏｎによって、特定のＤｅｃｉｓｉｏｎＮｏｄｅ　ｄ_ψに関連づけられている場合（図２４）、Ｐ_ｏｐｘのトークンは図５Bに示した（ｆ）Ｃｏｎｔｒｏｌ　ｗｉｔｈ　Ｃｏｎｄｉｔｉｏｎ　Ｉから変換されたトランジションｔ_{ｇｙｅｓψ}またはｔ_ｇｎｏψを発火可能にする。一方、トークンがＰ_{ｂｒａｎｃｈｘ}に存在する場合、遷移確率１－ｐ_１でｔ_{ｆａｉｌｘ}が発火する。その後、トークンは直接Ｐ_{ｆｉｎｉｓｈｘ}に移動する。トークンがＰ_{ｆｉｎｉｓｈｘ}に存在すると、前述した（１）における制御フローモデルのｔ_{ｇｆｉｎｉｓｈｘ}が発火可能になり、トークンがＰ_{ｒｅｔｕｒｎｘ}に移動する。トークンがＰ_{ｒｅｔｕｒｎｘ}に存在すると、復旧操作モデルのトークンは最初のプレースＰ_{ｂｅｆｏｒｅｘ}に再び戻る。復旧操作モデルにおいてトークンがＰ_{ｂｅｆｏｒｅｘ}に存在すると、制御フローモデルのｔ_{ｇｂｅｆｏｒｅｘ}が発火し、トークンが変換元のアクティビティ図において接続先となっている次のＡＤモジュールから変換された、次の（遷移先の）ＳＲＮモデルモジュールのプレースに移動する。

　図５Ｂに示す（ｄ）ＦｌｏｗＦｉｎａｌ　ｍｏｄｕｌｅは、一つのＦｌｏｗＦｉｎａｌを含む。ＦｌｏｗＦｉｎａｌモジュールは、図５Ｂに示す制御フローモデルの一つのプレースに変換される（図５Ｂの参照番号５Ｂ－Ｆ２１（図２１における２１０１））。このプレースは制御フローモデルの終了点の一つとなる。このプレースにトークンが存在する場合、障害復旧手順が完全な復旧をせずに終了したことを表す。

　図５Ｂに示す（ｅ）ＡｃｔｉｖｉｔｙＦｉｎａｌ　ｍｏｄｕｌｅは、一つのＡｃｔｉｖｉｔｙＦｉｎａｌを含む。ＡｃｔｉｖｉｔｙＦｉｎａｌ　ｍｏｄｕｌｅは、図５Ｂに示す制御フローモデルの一つのプレースに変換される（図５Ｂの参照番号５Ｂ－Ｆ２３（図２３における２３０１））。このプレースは、制御フローモデルの終了点の一つとなる。このプレースにトークンが存在する場合、障害復旧手順が完全な復旧を以って完了したことを示す。

　図５Ｂに示す（ｆ）”Ｃｏｎｔｒｏｌ　ｗｉｔｈ　ｃｏｎｄｉｔｉｏｎ　ｍｏｄｕｌｅＩ”は、前記したｓｔｅｒｅｏｔｙｐｅである＜＜ｃｏｎｔｒｏｌ＞＞を持つ、操作ｏｐ_ｘを表すＡｃｔｉｏｎから、ＤｅｃｉｓｉｏｎＮｏｄｅ　ｄ_θへのａｌｌｏｃａｔｉｏｎを一つ含む。”Ｃｏｎｔｒｏｌ　ｗｉｔｈ　ｃｏｎｄｉｔｉｏｎモジュールＩ”は、図５Ｂに示すシステム状態モデルとして、条件分岐ｄ_θを含むＤｅｃｉｓｉｏｎＮｏｄｅ　ｍｏｄｕｌｅから変換されたシステム状態モデルの二つのプレース（Ｐ_ｙｅｓ及びＰ_ｎｏ）を接続する、一つのトランジション、一つの入力アーク、一つの出力アークに変換される（図５Ｂの参照番号５Ｂ－Ｆ２５、図２５）。変換後の各プレース間の遷移の方向は、障害状態から正常に機能している状態へと規定される。遷移の方向は、システム設計者が決定する。例えば、条件分岐ｄ_θを含む特定のＤｅｃｉｓｉｏｎＮｏｄｅ　ｍｏｄｕｌｅからの出力”ｙｅｓ”が障害状態に相当するならば、遷移の方向はＰ_ｙｅｓψから、Ｐ_ｎｏψとなる。同様に、条件分岐ｄ_θの出力”ｎｏ”が障害状態に相当するならば、遷移の方向は、Ｐ_ｎｏψから、Ｐ_ｙｅｓψとなる。ガード関数ｇ_ｏｐｘにより、トークンがＰ_ｏｐｘに存在する場合のみ、ｔ_ｇｏｐｘが発火しトークンがＰ_ｙｅｓψまたはＰ_ｎｏψから、それぞれＰ_ｎｏψまたはＰ_ｙｅｓψへ移動する。

　図５Ｂに示す（ｇ）”Ｃｏｎｔｒｏｌ　ｗｉｔｈ　ｃｏｎｄｉｔｉｏｎ　ｍｏｄｕｌｅ　ＩＩ”は、前述したｓｔｅｒｅｏｔｙｐｅとして＜＜ｃｏｎｔｒｏｌ＞＞を持ち、ＤｅｃｉｓｉｏｎＮｏｄｅ　ｄ_ψからＤｅｃｉｓｉｏｎＮｏｄｅ　ｄ_θへの一つのａｌｌｏｃａｔｉｏｎを含む。”Ｃｏｎｔｒｏｌ　ｗｉｔｈ　ｃｏｎｄｉｔｉｏｎ　ｍｏｄｕｌｅ　ＩＩ”は、図５Ｂに示すシステム状態モデルとして、条件分岐ｄ_θを含むＤｅｃｉｓｉｏｎＮｏｄｅ　ｍｏｄｕｌｅから変換されたシステム状態モデルの二つのプレースを接続する、一つのトランジション、一つの入力アーク、一つの出力アークに変換される（図５Ｂの参照番号５Ｂ－Ｆ２７（図２７））。遷移の方向は、上記（ｆ）”Ｃｏｎｔｒｏｌ　ｗｉｔｈ　ｃｏｎｄｉｔｉｏｎ　ｍｏｄｕｌｅＩ”と同様である。ガード関数ｇ_ｙｅｓψまたはｇ_ｎｏψにより、トークンがＰ_ｙｅｓψまたはＰ_ｎｏψに存在する場合のみ、ｔ_{ｇｙｅｓψ}またはｔ_ｇｎｏψが発火し、トークンがＰ_ｙｅｓθまたはＰ_ｎｏθ　から、それぞれＰ_ｎｏθまたはＰ_ｙｅｓθへ移動する。

　図５Ｂに示す（ｈ）Ｐｒｉｏｒ　moduleは、前述したｓｔｅｒｅｏｔｙｐｅとして＜＜ｐｒｉｏｒ＞＞を持ち、操作ｏｐ_ｘを有するＡｃｔｉｏｎから、操作ｏｐ_ｙを有するＡｃｔｉｏｎへの一つのａｌｌｏｃａｔｉｏｎを含む。Ｐｒｉｏｒ　ｍｏｄｕｌｅは、図５Ｂに示すシステム状態モデルとして、条件分岐ｄ_θを含むＤｉｃｉｓｉｏｎＮｏｄｅ　ｍｏｄｕｌｅから変換されたシステム状態モデルの二つのプレースの間の一つの中間プレース、および、これら三つのプレース間を接続する、二つのトランジション、二つの入力アーク、二つの出力アークに変換される（図５Ｂの参照番号５Ｂ－Ｆ２９（図２９））。遷移の方向は、上記（ｆ）”Ｃｏｎｔｒｏｌ　ｗｉｔｈ　ｃｏｎｄｉｔｉｏｎ　ｍｏｄｕｌｅＩ”と同様である。ガード関数ｇ_ｏｐｘまたはｇ_ｏｐｙにより、トークンがＰ_ｏｐｘに移動し、その後トークンがＰ_ｏｐｙに移動した場合のみ、トークンはＰ_ｙｅｓθまたはＰ_ｎｏθから、それぞれＰ_ｎｏθまたはＰ_ｙｅｓθへ移動する。

　なお、他のノードまたはａｌｌｏｃａｔｉｏｎに対する変換規則は割愛するが、必要に応じて新しい変換規則を追加することで、特定のシステムに特化した拡張は容易に実施可能である。

　図７は、図６に示す障害復旧手順から生成された解析モデルの一部である制御フローモデルの一例を示した図である。

　図８は、図６に示す障害復旧手順から生成された解析モデルの一部である復旧手順モデルの一例を示した図である。

　図９は、図６に示す障害復旧手順から生成された解析モデルの一部であるシステム状態モデルの一例を示した図である。

　システム設計装置１における以後の処理、すなわち、図４に示すステップＳ１０３０～Ｓ１０７０の処理手順は、前記第１の実施形態における図２に示す手順と同様であり、同手順のステップＳ１０３０～ステップＳ１０７０を実施すればよいため、本実施形態における説明は省略する。

　　（第２の実施形態による効果）
　以上、説明したように、本発明の第２の実施形態に係るシステム設計装置によれば、第１の実施形態に係るシステム設計装置１と同様の作用および効果を奏することができる。

　さらに、本発明の第２の実施形態に係るシステム設計装置１によれば、システム設計者が作成したアクティビティ図から、ＳＲＮモデルによる解析モデルを自動生成することができる。このため、モデルベースの評価手法で必要とされる数理モデリングの専門知識を持たないシステム設計者でも、アクティビティ図等を用いて設計した障害復旧手順について、例えば復旧要件の充足可能性等を評価できる。

　＜第３の実施形態＞
　次に、本発明の第３の実施形態に係るシステム設計装置について説明する。コンポーネント障害について、発生しうる全ての障害の組み合わせに対する復旧時間とコストを計算する場合、コンポーネント数が増加するにつれ、解析のための計算量は急速に増加する。よって、解析対象となるコンポーネント障害の組合せを枝刈りにすることにより、計算量を削減できるとよい。

　本発明の第３の実施形態に係るシステム設計装置は、上述した第１及び第２の実施形態に係るシステム設計装置に対して、解析対象となるコンポーネント障害の組合せを枝刈りする構成を更に有している。以下、かかる構成を中心に説明する。

　　（機能）
　図１０に示したように、第３の実施形態に係るシステム設計装置１の機能は、第１又は第２の実施形態に係るシステム設計装置１の機能に加えて、最小組合せ特定部１０４に組合せ枝刈部１０９を含む。他の構成は上述した実施形態と同様であるので、本実施形態における説明は省略する。

　　（作動）
　次に、上述したシステム設計装置１の作動について、図１１を参照して説明する。先ず、本実施形態におけるシステム設計装置１は、例えば、前記第２の実施形態と同様に、図４に示すステップＳ１０１０～ステップＳ１０２０を実施する。

　次いで、システム設計装置１は、解析すべきコンポーネント障害の組合せを枝刈りする（図１１に示すステップＳ１０２１）。以下、ステップＳ１０２１における、具体的な枝刈りの方法について説明する。

　まず、ステップＳ１０１０にて入力されるアクティビティ図において、ＦｌｏｗＦｉｎａｌに至るコンポーネント障害の組み合わせは、システムの完全な復旧状態に到達しない。このため、このような組合せは解析対象から除く。

　次に、異なるコンポーネント障害の組み合わせに対する障害復旧手順が同じ場合は、最初の一回のみ解析して、重複を排除する。例えば、物理サーバに障害が起きた場合、当該物理サーバ上において動作していたＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）については、当該ＯＳ自身の障害発生の有無に関わらず、物理サーバの復旧後に復旧しなければならない。他の例として、あるコンポーネントが正常稼働中だが、そのコンポーネントのためのバックアップファイルが破損している場合、バックアップファイルの早急な復旧は望ましいがシステム全体の復旧に必須ではない。

　次いで、システム設計装置１は、第２の実施形態におけるステップＳ１０５０と同様に、復旧時間とコストの要求を受け付ける（図１１に示すステップＳ１０２２）。

　次いで、システム設計装置１は、含まれるコンポーネントの障害数が最小となる組合せの中から、一つのコンポーネント障害の組合せを取り出す（図１１に示すステップＳ１０２３）。このとき、まだ一度も取り出されておらず、かつ、含まれるコンポーネント障害の数が最小となるような組合せの中から選ぶものとする（一度取り出した組合せは二度と取り出されないものとする）。このとき、上記取り出した一つの組合せが、復旧時間とコストの要求を満たさない、要件違反の既知のコンポーネント障害の組合せを含む場合は、当該組合せは解析対象外として、ステップＳ１０２３に戻る（図１１に示すステップＳ１０２４においてＹｅｓの場合）。なぜならば、当該組合せは、含まれるコンポーネント障害数が最小の組合せより多くなるため、最小の組合せになりえないからである。一方、それ以外の場合は、ステップＳ１０３０へ進む（図１１に示すステップＳ１０２４においてＮｏの場合）。

　次いで、上記取り出された組合せについて、第２の実施形態と同様に、ステップ１０３０～ステップ１０４０を実施する。

　次に、全ての組合せについて取り出しを終了した場合は、ステップＳ１０６０へ進み（図１１に示すステップＳ１０４１においてＹｅｓの場合）、第２の実施形態と同様に、ステップＳ１０６０～ステップＳ１０７０を実施する。一方、図１１に示すステップＳ１０４１においてＮｏの場合は、ステップＳ１０２３に戻り、処理を継続する。

　　（実施例３の効果）
　以上、説明したように、本発明の第３の実施形態に係るシステム設計装置によれば、第１及び第２の実施形態に係るシステム設計装置１と同様の作用および効果を奏することができる。さらに、本発明の第３の実施形態に係るシステム設計装置１によれば、コンポーネントの組合せの枝刈りを行うことで、解析に要する計算量を削減できる。

　以上、上記実施形態を参照して本願発明を説明したが、本願発明は、上述した実施形態に限定されるものではない。係る実施形態において例示した、本願発明の構成ついては、本願発明の技術的範囲内において、当業者が理解し得る様々な変更又は改良を加えることが可能である。そのような場合、係る変更又は改良を加えた新たな実施形態も、本発明の技術的範囲に含まれ得る。

　なお、上記各実施形態において、評価指標として復旧時間とコストを用いたが、他のシステム要件に関わる評価指標を用いてもよい。

　また、上記各実施形態において、復旧時間をシステムが障害から完全復旧するまでの時間としたが、例えば、障害復旧時間を、システムの重要な部分だけが復旧するまでの時間としてもよい。

　また、上記各実施形態において、コンポーネント障害の最小の組合せが複数存在する場合は、最小の組合せを出力する際に、当該複数存在する最小の組合せをランクづけしてもよい。例えば、各組合せを、障害復旧時間または所要コストの要件を超過した度合に応じてランク付けしてもよい。また、コンポーネント障害ごとに重みづけをし、重みの合計によりランク付けしてもよい。

　また、上記各実施形態においてシステム設計装置１の各機能は、ＣＰＵがプログラム（ソフトウェア）を実行することにより実現されていたが、専用の回路等のハードウェア装置により実現されていてもよい。

　また、上記各実施形態においてプログラムは、記憶装置に記憶されていたが、コンピュータが読み取り可能な記録媒体に記憶されていてもよい。例えば、記録媒体は、フレキシブルディスク、光ディスク、光磁気ディスク、及び、半導体メモリ等の可搬性を有する媒体である。

　また、上記実施形態の他の変形例として、上述した実施形態及び変形例の任意の組み合わせが採用されてもよい。

　本発明は、情報処理システムの障害復旧のためのシステムの設計を支援するシステム設計装置などに適用して好都合である。

　　　　１　システム設計装置
　　１００　解析モデル受付部
　　１０１　障害復旧手順受付部
　　１０２　解析モデル生成部
　　１０３　モデルモジュール
　　１０４　最小組合せ特定部
　　１０５　要件受付部
　　１０６　最小組合せ出力部
　　１０７　復旧時間推定部
　　１０８　コスト推定部
　　１０９　組合せ枝刈部

Claims

　システムの障害復旧手順を表す解析モデルを受け付ける手段と、
　受け付けた解析モデルから、復旧時間または所要コストの要件を満たさないコンポーネント障害の最小の組合せを特定する手段と、
　特定したコンポーネント障害の最小の組合せを出力する手段と、を備え、
　前記コンポーネント障害の最小の組合せを特定する手段は、
　　前記システムの復旧時間を推定する手段と、
　　前記システムの復旧に要するコストを推定する手段と、
　を有するシステム設計装置。
　システムの障害復旧手順を受け付ける手段と、
　受け付けた障害復旧手順から、モデルモジュールを組み合わせて解析モデルを生成する解析モデル生成部と、
　生成した解析モデルから、復旧時間または所要コストの要件を満たさないコンポーネント障害の最小の組合せを特定する手段と、
　特定したコンポーネント障害の最小の組合せを出力する手段と、を備え、
　前記コンポーネント障害の最小の組合せを特定する手段は、
　　前記システムの復旧時間を推定する手段と、
　　前記システムの復旧に要するコストを推定する手段と、
　を有するシステム設計装置。
　請求項２に記載のシステム設計装置であって、
　更に、解析の不要なコンポーネントの障害の組合せを枝刈りする組合せ枝刈部を備えるシステム設計装置。
　前記解析モデルは、特定の確率分布に基づいて状態遷移が起こる状態遷移モデルである、請求項1乃至請求項３の何れかに記載のシステム設計装置。
　前記障害復旧手順は、少なくとも、障害が発生したコンポーネントの状態に関する情報か、または障害が発生したコンポーネントを復旧するための障害復旧操作に関する情報か、または前記障害復旧操作が実行される条件に関する情報を含み、
　前記解析モデル生成部は、
　　予め定められた前記障害復旧手順と前記解析モデルとの間の変換規則に基づいて、前記障害復旧手順に含まれる、前記システムの状態に関する情報と、障害復旧操作に関する情報と、障害復旧操作が実行される条件に関する情報とを、それぞれ前記解析モデルを構成する要素に変換し、
　　前記変換した前記解析モデルを構成する要素を統合して、前記解析モデルを生成する、
　請求項２乃至請求項４の何れかに記載のシステム設計装置。
　前記システムの障害復旧に関する、復旧時間と、復旧に要するコストの要件を受け付ける手段を更に有し、
　前記コンポーネント障害の最小の組合せを特定する手段は、
　　前記受け付けた解析モデルに基づいて、前記システムの復旧時間と、前記システムの復旧に要するコストを推定し、
　　前記受け付けた、復旧時間と復旧に要するコストの要件と、前記推定した復旧時間と復旧に要するコストに基づいて、前記復旧時間または所要コストの要件を満たさないコンポーネント障害の最小の組合せを特定する、
請求項１乃至請求項５の何れかに記載のシステム設計装置。
　システムの障害復旧手順を表す解析モデルを受け付け、
　受け付けた解析モデルから、復旧時間または所要コストの要件を満たさないコンポーネント障害の最小の組合せを特定し、
　特定したコンポーネント障害の最小の組合せを出力する、システム設計方法であって、
　前記コンポーネント障害の最小の組合せを特定する際に、
　前記システムの復旧時間を推定し、
　前記システムの復旧に要するコストを推定する、
　システム設計方法。
　システムの障害復旧手順を表す解析モデルを受け付け、
　前記システムの障害復旧に関する、復旧時間と、復旧に要するコストの要件を受け付け、
　前記受け付けた解析モデルに基づいて、前記システムの復旧時間と、前記システムの復旧に要するコストを推定し、
　前記受け付けた、復旧時間と復旧に要するコストの要件と、前記推定した復旧時間と復旧に要するコストに基づいて、前記復旧時間または所要コストの要件を満たさないコンポーネント障害の最小の組合せを特定し、
　前記特定したコンポーネント障害の最小の組合せを出力する、システム設計方法。
　情報処理装置に、
　システムの障害復旧手順を表す解析モデルを受け付ける手段と、
　受け付けた解析モデルから、復旧時間または所要コストの要件を満たさないコンポーネント障害の最小の組合せを特定する手段と、
　特定したコンポーネント障害の最小の組合せを出力する手段と、
　を実現させるためのシステム設計プログラムであって、
　前記コンポーネント障害の最小の組合せを特定する手段は、
　前記システムの復旧時間を推定する手段と、
　前記システムの復旧に要するコストを推定する手段と、
　を有するシステム設計プログラム。
　システムの障害復旧手順を設計するシステム設計ブログラムであって、
　前記システムの障害復旧手順を表す解析モデルを受け付ける処理と、
　前記システムの障害復旧に関する、復旧時間と復旧に要するコストの要件を受け付ける処理と、
　前記受け付けた解析モデルに基づいて、前記システムの復旧時間と、前記システムの復旧に要するコストを推定する処理と、
　前記受け付けた、復旧時間と復旧に要するコストの要件と、前記推定した復旧時間と復旧に要するコストに基づいて、前記復旧時間または所要コストの要件を満たさないコンポーネント障害の最小の組合せを特定する処理と、
　前記特定したコンポーネント障害の最小の組合せを出力する処理と、
　をコンピュータに実行させる、システム設計プログラム。