JP2008065682A - トレーサビリティ管理装置、プログラム、およびトレース方法 - Google Patents

Abstract

【課題】ハードウェアに変更や追加が行われた場合であっても、障害や要求のトレーサビリティを確保して、障害の影響範囲を効率的かつ正確に特定することを可能とするトレーサビリティ管理装置を提供する。
【解決手段】ハードウェア情報取得部１２０は、管理対象の半導体製造装置２のハードウェア構成に変更・追加がなされた場合に、その更新情報を取得する。障害の影響範囲を調査する際には、まずソフトウェア条件合致装置抽出部１５０が障害に係るソフトウェアがインストールされた装置を抽出する。続いて、ハードウェア条件合致装置抽出部１６０が抽出された装置が障害の発生するハードウェア条件を充足するか否かをハードウェア情報取得部１２０が取得した情報に基づいて判断し、充足する場合には当該装置を障害の影響を受ける装置として抽出する。
【選択図】図２

Description

この発明は、ハードウェアに依存する障害や、ソフトウェアからの機能要求のトレーサビリティに関する。

近年においては、製造販売業者にとって、自らの製造販売した製品の追跡性、すなわちトレーサビリティを確保することの重要性が高まっている。例えば、自らが製造販売した製品に欠陥が見つかった場合に、販売した製品のトレーサビリティが十分に確保されていないとすると、障害の影響範囲の特定を速やかに行うことができず、欠陥装置の使用者に対する警告や欠陥装置の回収といった措置を迅速に講じることができないからである。

ソフトウェアをインストールしたコンピュータ装置の製造販売においても、販売した製品のトレーサビリティを確保することは、やはり重要である。例えば、コンピュータ装置にインストールされたソフトウェア上にバグ等の障害が見つかった場合、トレーサビリティが確保されていなければ当該障害の影響範囲を速やかに特定する（つまりは、障害の影響を受けるコンピュータ装置を速やかに特定する）ことができず、甚大な被害を招きかねないからである。

ところでソフトウェア上の障害には、特定のハードウェア条件の下で発生する障害（例えば、特定の種類のＣＰＵで発生する障害、メモリサイズが所定値以下の場合に発生する障害）もある。このような類の障害の場合、障害の影響範囲を正確に特定するためにはコンピュータ装置それぞれについてのハードウェア情報を持っておく必要がある。

また、ソフトウェアによっては、当該ソフトウェアに記述された命令等を実行するために特定のハードウェア条件を要求するもの（例えば、正常に機能するためには特定のＣＰＵや所定値以上のメモリサイズを必要とするソフトウェア）がある。ソフトウェアからこのような機能要求が出された場合、機能要求を充足する装置を特定するためには、やはりコンピュータ装置それぞれについてのハードウェア情報が必要となる。

従来においては、ハードウェアの種類毎に型番を命名し、この型番によってハードウェア情報を管理することによって、コンピュータ装置とのトレーサビリティを確保する構成がとられていた。このような管理方法の場合、例えば、特定の種類のＣＰＵで発生する障害がソフトウェア上に見つかった場合、コンピュータの型番から当該コンピュータの備えるＣＰＵの種類を特定して、その障害が当該コンピュータに影響するか否かを判断していた。（例えば、特許文献１参照。）

特開平１０−８３３２２号公報

しかしながら、一般に、コンピュータ装置のハードウェアには変更や追加が可能な要素が含まれているため、装置のハードウェア構成はその初期状態（すなわち、型番から規定される装置構成の状態）に固定されているとは限らず、そこから動的に変化する可能性がある。つまり、コンピュータ装置のハードウェア要素が変更・追加された場合（例えば、ＣＰＵやマザーボードの交換、メモリの増設等が行われた場合）、当該コンピュータ装置の実際のハードウェア構成は型番から規定されるハードウェア構成と一致しなくなってしまう。

したがって、型番によってハードウェア情報を管理する従来の方法では、ハードウェア構成が変更・追加された装置とはもはや適正なトレーサビリティが確保されているとはいえず、障害の影響範囲を正しく特定することもソフトウェアが要求する機能を充足するハードウェアを正しく特定することもできなかった。

この発明は、上記課題に鑑みてさなれたものであり、ハードウェアに変更や追加が行われた場合であっても、障害や要求のトレーサビリティを確保して、障害の影響範囲や、機能要求の充足可能範囲の特定を効率的かつ正確に行うことを可能とするトレーサビリティ管理装置、トレース方法、およびプログラムを提供することを目的とする。

請求項１の発明は、変更もしくは追加可能なハードウェア要素を備える複数のコンピュータ装置のトレーサビリティを提供するトレーサビリティ管理装置において、前記複数のコンピュータ装置それぞれのインストール履歴を取得するソフトウェア情報取得手段と、前記複数のコンピュータ装置それぞれの前記ハードウェア要素に関する更新情報を取得するハードウェア情報取得手段と、ソフトウェア上の障害の影響範囲をトレースするにあたって、前記複数のコンピュータ装置の中から前記障害を含むソフトウェアがインストールされた装置を抽出する第１の装置抽出手段と、前記複数のコンピュータ装置の中から前記障害が発生するハードウェア条件を充足する装置を抽出する第２の装置抽出手段と、を備え、前記複数のコンピュータ装置の中で、前記第１の装置抽出手段で抽出されかつ前記第２の装置抽出手段で抽出された装置を障害該当コンピュータ装置に特定する。

請求項２の発明は、変更もしくは追加可能なハードウェア要素を備える複数のコンピュータ装置のトレーサビリティを提供するトレーサビリティ管理装置において、前記複数のコンピュータ装置それぞれのインストール履歴を取得するソフトウェア情報取得手段と、前記複数のコンピュータ装置それぞれの前記ハードウェア要素に関する更新情報を取得するハードウェア情報取得手段と、ソフトウェアからの機能要求を充足する範囲をトレースするにあたって、前記複数のコンピュータ装置の中から前記機能要求に係るソフトウェアがインストールされた装置を抽出する第１の装置抽出手段と、前記複数のコンピュータ装置の中から前記ソフトウェアから要求されるハードウェア条件を充足する装置を抽出する第２の装置抽出手段と、を備え、前記複数のコンピュータ装置の中で、前記第１の装置抽出手段で抽出されかつ前記第２の装置抽出手段で抽出された装置を要求充足コンピュータ装置に特定する。

請求項３の発明は、コンピュータのＣＰＵとメモリを利用して、請求項１または請求項２に記載のトレーサビリティ管理装置として機能させる。

請求項４の発明は、変更もしくは追加可能なハードウェア要素を備える複数のコンピュータ装置にインストールされるソフトウェア上の障害のトレース方法において、前記複数のコンピュータ装置それぞれのインストール履歴を取得するソフトウェア情報取得工程と、前記複数のコンピュータ装置それぞれの前記ハードウェア要素に関する更新情報を取得するハードウェア情報取得工程と、前記複数のコンピュータ装置の中から前記障害を含むソフトウェアがインストールされた装置を抽出する第１の装置抽出工程と、前記第１の装置抽出工程で抽出された装置の中から、前記障害が発生するハードウェア条件を充足する装置を抽出する第２の装置抽出工程と、を備える。

請求項５の発明は、変更もしくは追加可能なハードウェア要素を備える複数のコンピュータ装置にインストールされるソフトウェアからの機能要求のトレース方法において、前記複数のコンピュータ装置それぞれのインストール履歴を取得するソフトウェア情報取得工程と、前記複数のコンピュータ装置それぞれの前記ハードウェア要素に関する更新情報を取得するハードウェア情報取得工程と、前記複数のコンピュータ装置の中から前記機能要求に係るソフトウェアがインストールされた装置を抽出する第１の装置抽出工程と、前記第１の装置抽出工程で抽出された装置の中から、前記ソフトウェアから要求されるハードウェア条件を充足する装置を抽出する第２の装置抽出工程と、を備える。

請求項１、４に記載の発明によると、コンピュータ装置のハードウェア要素に関する更新情報を取得するので、ハードウェアに変更や追加が行われた場合であっても、コンピュータ装置とのトレーサビリティを確実に確保することができる。また、これによって、ハードウェア条件に依存する障害の影響範囲を効率的かつ正確に特定することができる。

また、請求項２、５に記載の発明によると、コンピュータ装置のハードウェア要素に関する更新情報を取得するので、ハードウェアに変更や追加が行われた場合であっても、コンピュータ装置とのトレーサビリティを確実に確保することができる。また、これによって、機能要求を充足する範囲を効率的かつ正確に特定することができる。

〈１．構成〉
図１は、この発明の実施の形態に係るトレーサビリティ管理装置１の構成を示す図である。トレーサビリティ管理装置１は、管理対象となる装置とのトレーサビリティを確保して、ソフトウェア上に障害が発生した場合に、当該障害が影響する装置をトレースして抽出する（換言すると、障害の影響範囲を調査する）機能および、ソフトウェアからの機能要求が出された場合に、当該機能要求を充足する装置をトレースして抽出する（換言すると、要求の充足可能範囲を調査する）機能を有している。以下においてこの機能を、「障害・要求のトレーサビリティ機能」という。

〈１−０．管理対象となる装置の構成〉
トレーサビリティ管理装置１は、変更もしくは追加可能なハードウェア要素を備えるとともに、変更もしくは追加可能なソフトウェア要素（モジュール）を有するコンピュータ装置を管理対象とする。以下においては、トレーサビリティ管理装置１が、基板（より具体的には、半導体基板、液晶表示用ガラス基板、フォトマスク用ガラス基板、光ディスク用の基板など）の製造に関する各種の処理を実行する半導体製造装置２を管理する場合について説明する。

〈ソフトウェア構成〉
半導体製造装置２は、ハードウェア各部を制御するためのソフトウェア（アプリケーションソフトウェア）がインストールされることによって、基板に対する所定の処理を実行可能な装置として機能する。また、アプリケーションソフトウェアがバージョンアップされると、各半導体製造装置２のオペレータによって、新たなバージョンのアプリケーションソフトウェアがインストール（アップデート）される。

後に詳述するように、トレーサビリティ管理装置１は、管理対象の半導体製造装置２それぞれにインストールされたソフトウェアに関する情報を管理している（インストール履歴テーブルＴ１（図３（ａ）参照））。特に、半導体製造装置２に新たなバージョンのアプリケーションソフトウェアがインストールされた場合には、その情報（インストール履歴情報）がトレーサビリティ管理装置１によって取得される。

なお、アプリケーションソフトウェアは、複数個（例えば、数１０個〜数１００個）のソフトウェア要素（モジュール）から構成されている。これらモジュールは、それぞれに修正や改良が加えられて適宜バージョンアップされていく。つまり、１個のアプリケーションソフトウェアは、変更や追加が可能な複数のソフトウェア要素（モジュール）から構成されている。

後に詳述するように、トレーサビリティ管理装置１は、各モジュールのバージョン情報や各アプリケーションソフトウェアのバージョン情報、また、各バージョンのアプリケーションソフトウェアに含まれるモジュールバージョンの情報を管理している（モジュールバージョンテーブルＴ５（図５（ａ））、アプリケーションバージョンテーブルＴ６（図５（ｂ））、バージョン対応テーブルＴ７（図５（ｃ））参照）。

〈ハードウェア構成〉
半導体製造装置２のハードウェアは、複数のハードウェア要素の組み合わせで構成されている。なお、以下においてハードウェアの構成要素を「リソース」という。

リソースの中には、変更もしくは追加可能なものが含まれている。変更・追加可能なリソースとは、例えば、各ユーザの注文に応じて付けられたオプション部品や選択部品（例えば、オプションで付けられたセンサ）や、交換・追加が可能な部品（例えば、ＣＰＵ、メモリ）等である。このため、同じ型番のハードウェアであっても必ずしも全部品が同一であるとは限らない（換言すると、各リソースのリソース値が全て一致するとは限らない）。また、ハードウェア構成が出荷時の状態のままで固定的に維持されるとの保証もない（換言すると、リソース値は出荷時の値から動的に変化する可能性がある）。

後に詳述するように、トレーサビリティ管理装置１は、管理対象の半導体製造装置２それぞれのハードウェア構成に関する情報を管理している（ハードウェア詳細情報テーブルＴ２（図３（ｂ）参照））。特に、半導体製造装置２のハードウェア構成に変更・追加が行われた場合には、その情報（より具体的には、変更に係るリソースのリソース値）がトレーサビリティ管理装置１によって取得される。つまり、トレーサビリティ管理装置１は、管理対象の半導体製造装置２のハードウェアが変更・追加された場合であっても、変更・追加情報を反映させた正しいハードウェア情報を保持することができる。

〈１−１．トレーサビリティ管理装置の構成〉
トレーサビリティ管理装置１は、コンピュータによって実現される。より具体的には、ＣＰＵ１１ａ、ＲＯＭ１１ｂ、およびＲＡＭ１１ｃから構成され、後述する各機能を実現する制御部１１と、このコンピュータをトレーサビリティ管理装置１として機能させるためのプログラムＰなどを格納するための記憶部１２と、オペレータが各種の指示を入力するためのマウスやキーボードなどからなる操作部１３と、ディスプレイ等の表示部１４と、ハードディスクなどにより構成され、メディアリーダ／ライタ１５１を通じて記録媒体Ｍとの間でデータのリード／ライトを行うためのＲ／Ｗ部１５と、ネットワークＮ上の他の装置との間でデータの受け渡しを行うためのインターフェースである通信部１６とを主として備えている。

〈１−２．障害・要求のトレーサビリティに関する構成〉
図２は、障害・要求のトレーサビリティ機能に関する構成を説明する図である。

なお、トレーサビリティ管理装置１は、管理する半導体製造装置２のそれぞれに対して各装置を識別するための個別のシリアル番号を付与し、このシリアル番号の下に各装置を管理する。

トレーサビリティ管理装置１は、障害・要求のトレーサビリティ機能に関する構成として、ソフトウェア情報取得部１１０と、ハードウェア情報取得部１２０と、障害・要求情報取得部１３０と、アプリケーションバージョン特定部１４０と、ソフトウェア条件合致装置抽出部１５０と、ハードウェア条件合致装置抽出部１６０とを備えている。これら各部は、制御部１１が記憶部１２に記憶されている所定のプログラムＰを実行することにより実現される構成要素である。また、トレーサビリティ管理装置１の記憶部１２は、管理対象装置とのトレーサビリティを確保するとともに、障害の影響範囲や機能要求の充足範囲を調査する際に参照するテーブルＴ１〜Ｔ７が格納されている。

ソフトウェア情報取得部１１０は、管理対象の半導体製造装置２に新たなバージョンのアプリケーションソフトウェアがインストールされた場合に、そのインストール履歴情報（より具体的には、インストールされたソフトウェアのアプリケーションバージョン番号とインストールが行われた日時）を取得する。ただし、アプリケーションバージョン番号とは、各アプリケーションバージョンに付与された番号であり、アプリケーションバージョンとアプリケーションバージョン番号との対応関係はアプリケーションバージョンテーブルＴ６（図５（ｂ））に記憶されている。

なお、インストール履歴情報は、アプリケーションソフトウェアがインストールされた半導体製造装置２からネットワークＮを介して取得してもよいし、インストール履歴情報を格納した記録媒体Ｍから読み取って取得してもよい。また、オペレータに操作部１３からインストール履歴情報を入力させて当該入力操作に基づいてインストール履歴情報を取得する構成としてもよい。

ソフトウェア情報取得部１１０が取得した情報は、半導体製造装置２のシリアル番号と対応付けられて、インストール履歴テーブルＴ１（図３（ａ））に格納される。

〈インストール履歴テーブルＴ１〉
図３（ａ）を参照する。インストール履歴テーブルＴ１は、管理対象の半導体製造装置２のインストール履歴情報を管理するテーブルである。インストール履歴テーブルＴ１は、「シリアル番号」「アプリケーションバージョン番号」「日時」の各項目を有している。

例えば、２００６年５月８日に、シリアル番号「１２３４５」の半導体製造装置２にバージョン１.１０（すなわち、アプリケーションバージョン番号Ａ２（図５（ｂ）参照））のアプリケーションソフトウェアがインストールされた場合、ソフトウェア情報取得部１１０は当該インストール履歴情報として、当該半導体製造装置２のシリアル番号「１２３４５」と、インストールの日時「２００６／５／８」と、インストールされたアプリケーションソフトウェアのアプリケーションバージョン番号「Ａ２」とを取得する。取得されたインストール履歴情報は半導体製造装置２のシリアル番号「１２３４５」と対応付けてインストール履歴テーブルＴ１の「日時」「アプリケーションバージョン番号」の各項目にそれぞれ格納される。

再び図２を参照する。ハードウェア情報取得部１２０は、管理対象の半導体製造装置２のハードウェア構成に変更・追加がなされた場合に、その更新情報を取得する。

ハードウェア構成に関する更新情報についてより具体的に説明する。トレーサビリティ管理装置１は、管理対象となる半導体製造装置２のハードウェア情報をリソース単位で管理している。すなわち、ハードウェアを構成する全てのリソースのそれぞれについての具体的内容を示す情報（リソース値）を保持することによって、ハードウェア構成全体の情報を管理している。

したがって、ハードウェア情報取得部１２０は、管理対象の半導体製造装置２のハードウェア構成に変更・追加がなされた場合に、その更新情報として、変更・追加に係るリソースと、変更・追加後のリソース値と、変更・追加が行われた日時とを取得する。

なお、ハードウェア構成に関する更新情報は、ハードウェアが変更・追加された半導体製造装置２からネットワークＮを介して取得してもよいし、ハードウェアの更新情報を格納した記録媒体Ｍから読み取って取得してもよい。また、オペレータに操作部１３からハードウェアの更新情報を入力させて当該入力操作に基づいて更新情報を取得する構成としてもよい。

また、各半導体製造装置２のハードウェア構成の初期情報については、更新情報と同様の態様で取得するとしてもよいし、各装置の型番から取得する構成としてもよい。すなわち、各半導体製造装置２の型番をシリアル番号と対応付けて記憶したテーブルおよび型番毎のハードウェア情報（より具体的にはリソース値）を格納したテーブルを予めを記憶部１２に格納しておき、これら各テーブルを参照することによって各ハードウェア構成の初期情報を取得する構成としてもよい。

ハードウェア情報取得部１２０が取得した情報は、半導体製造装置２のシリアル番号と対応付けられて、ハードウェア詳細情報テーブルＴ２（図３（ｂ））に格納される。

〈ハードウェア詳細情報テーブルＴ２〉
図３（ｂ）を参照する。ハードウェア詳細情報テーブルＴ２は、管理対象の半導体製造装置２のハードウェア情報を管理するテーブルであり、より具体的には、管理対象の半導体製造装置２の各リソースに係るリソース値を管理するテーブルである。ハードウェア詳細情報テーブルＴ２は、「シリアル番号」「リソース」「リソース値」「日時」の各項目を有している。

例えば、２００４年２月１日に、シリアル番号「１２３４５」の半導体製造装置２においてメモリが５１２ＭＢに増設された場合、ハードウェア情報取得部１２０はハードウェア構成に関する更新情報として、当該半導体装置のシリアル番号「１２３４５」と、変更・追加が行われた日時「２００４／２／１」と、変更・追加に係るリソース「MEMORY#SIZE」およびそのリソース値「５１２」とを取得する。取得された情報は、半導体製造装置２のシリアル番号「１２３４５」と対応付けてハードウェア詳細情報テーブルＴ２の「日時」「リソース」「リソース値」の各項目にそれぞれ格納される。これによって、ハードウェアに対して行われた変更・追加が反映され、変更・追加後のハードウェア構成に一致した正しいハードウェア情報がハードウェア詳細情報テーブルＴ２に保持されることになる。

再び図２を参照する。障害・要求情報取得部１３０は、ソフトウェア上の障害や、ソフトウェアからの機能要求に関する情報を取得する。ただし、ソフトウェア上の障害やソフトウェアからの機能要求は、アプリケーションソフトウェアに含まれる特定のモジュールに起因している。換言すると、障害や機能要求は特定のモジュールに結びついている。

障害・要求に関する情報とは、より具体的には、障害・要求の発生日時と、障害が発生する（もしくはソフトウェアが正常に機能するための）ハードウェア条件番号と、障害・要求に係るモジュールバージョンを特定するための情報（より具体的には、障害が混入したモジュールバージョン番号、障害が修正された場合には障害が解消したモジュールバージョン番号、もしくは要求を出したモジュールバージョン番号）である。ただし、ハードウェア条件番号が示す具体的なハードウェアの条件は、ハードウェア条件テーブルＴ４（図４（ｃ））に記述される。例えば図４（ｃ）に示される例によると、ハードウェア条件番号「１０」は、「メモリサイズが５１２ＭＢ以下」とのハードウェア条件であることがわかる。また、モジュールバージョン番号とは、各モジュールバージョンに付与された番号であり、モジュールバージョンとモジュールバージョン番号との対応関係はモジュールバージョンテーブルＴ５（図５（ａ））に記憶されている。

なお、障害・要求に関する情報は、ネットワークＮを介して接続された通信端末装置から取得してもよいし障害・要求に関する情報を格納した記録媒体Ｍから読み取って取得してもよい。また、障害や要求が発生する度にオペレータに操作部１３から当該障害・要求に関する情報を入力させて当該入力操作に基づいて障害・要求に関する情報を取得する構成としてもよい。障害・要求情報取得部１３０が取得した情報は、障害・要求テーブルＴ３に格納される。

〈障害・要求テーブルＴ３〉
図４（ａ）（ｂ）を参照する。障害・要求テーブルＴ３は、ソフトウェア上の障害や、ソフトウェアからの機能要求に関する情報を管理するテーブルである。トレーサビリティ管理装置１は、障害・要求テーブルＴ３として、障害テーブルＴ３ａと要求テーブルＴ３ｂとの２種類のテーブルを有している。

〈障害テーブルＴ３ａ〉
障害テーブルＴ３ａは、「障害番号」「発生日時」「ハードウェア条件番号」「障害混入モジュールバージョン番号」「障害修正モジュールバージョン番号」の各項目を有している。

例えば、２００６年５月１０日に、モジュールバージョン番号Ｍ３に障害が発生し、この障害がメモリサイズが５１２ＭＢ以下のハードウェア条件のもとで発生することがわかった場合、障害・要求情報取得部１３０は、障害が発生した日時「２００６／５／１０」と、メモリサイズ５１２ＭＢ以下を規定するハードウェア条件番号「１０」と、障害が混入したモジュールバージョン番号「Ｍ３」とを取得する。取得された情報は障害番号「９００１」と対応付けて障害テーブルＴ３ａの「発生日時」「ハードウェア条件番号」「障害混入モジュールバージョン番号」の各項目にそれぞれ格納される。また、モジュールバージョン番号Ｍ４においてこの障害が修正された場合、障害・要求情報取得部１３０は、障害が修正されたモジュールバージョン番号「Ｍ４」を取得する。取得された情報は障害番号「９００１」と対応付けて障害テーブルＴ３ａの「障害修正モジュールバージョン番号」の項目に格納される。

〈要求テーブルＴ３ｂ〉
要求テーブルＴ３ｂは、「要求番号」「発生日時」「ハードウェア条件番号」「対応モジュールバージョン番号」の各項目を有している。

例えば、２００５年６月１日に、モジュールバージョン番号Ｍ３から機能要求が出され、この機能要求がＣＰＵがＰ３型のハードウェア条件を要求するものである場合、障害・要求情報取得部１３０は、要求が出された日時「２００５／６／１」と、ＣＰＵタイプＰ３を規定するハードウェア条件番号「１１」と、要求を出したモジュールバージョン番号「Ｍ３」とを取得する。取得された情報は要求番号「６００１」と対応付けて要求テーブルＴ３ｂの「発生日時」「ハードウェア条件番号」「対応モジュールバージョン番号」の各項目にそれぞれ格納される。

〈ハードウェア条件テーブルＴ４〉
ここで、ハードウェア条件テーブルＴ４について説明する。上述の通り、ハードウェア条件テーブルＴ４は、ハードウェア条件番号が示す具体的なハードウェアの条件を規定するテーブルである。

ハードウェア条件テーブルＴ４は、「ハードウェア条件番号」「リソース」「リソース値」「比較演算子」の各項目を有している。

「リソース」の項目には条件付けの対象となるリソースの種類が、「リソース値」の項目には要求されるリソースの内容が、「比較演算子」の項目にはリソース値を比較する式で用いるべき演算子（例えば、「＝」、「＜＝」、「＞＝」）が、それぞれ記述される。例えば、図４（ｃ）に例示されるハードウェア条件テーブルＴ４においては、ハードウェア条件番号「１０」で、リソース「MEMORY#SIZE」がリソース値「５１２」ＭＢ以上（「＜＝」）とのハードウェア条件を規定している。

再び図２を参照する。アプリケーションバージョン特定部１４０は、障害・要求に係るアプリケーションバージョン番号を特定する。より具体的には、モジュールバージョンテーブルＴ５に格納されたモジュールバージョンの中から障害・要求に係るモジュールバージョンを抽出し、さらにアプリケーションバージョンテーブルＴ６に格納されたアプリケーションバージョンの中から障害・要求に係るモジュールバージョンを含むアプリケーションバージョンを、障害・要求に係るアプリケーションバージョンとして抽出する。

〈モジュールバージョンテーブルＴ５〉
モジュールバージョンテーブルＴ５は、各モジュールバージョンを、モジュールバージョン番号の下で規定するテーブルである。新たなバージョンのモジュールが作成された場合には、当該モジュールバージョンに関する情報が、図示しないモジュールバージョン情報取得手段によって取得されて、所定のモジュールバージョン番号と関連づけてモジュールバージョンテーブルＴ５に格納される。

モジュールバージョンテーブルＴ５は、「モジュールバージョン番号」の項目と、バージョンアップされたモジュールの種類が記述される「モジュール」の項目と、モジュールのバージョン情報が記述される「モジュールバージョン」の項目と、当該モジュールバージョンが出された日時が記述される「日時」の項目と、当該モジュールバージョンに親モジュールバージョンが存在する場合に当該親モジュールのバージョン番号が記述される「親モジュールバージョン番号」の項目とを有している。

〈アプリケーションバージョンテーブルＴ６〉
アプリケーションバージョンテーブルＴ６は、各アプリケーションバージョンを、アプリケーションバージョン番号の下で規定するテーブルである。新たなバージョンのアプリケーションが作成された場合には、当該アプリケーションバージョンに関する情報が、図示しないアプリケーションバージョン情報取得手段によって取得されて、所定のアプリケーションバージョン番号と関連づけてアプリケーションバージョンテーブルＴ６に格納される。

アプリケーションバージョンテーブルＴ６は、アプリケーションのバージョン情報が記述される「アプリケーションバージョン」の項目と、当該アプリケーションバージョンが出された日時が記述される「日時」の項目と、当該アプリケーションバージョンに親アプリケーションバージョンが存在する場合には当該親アプリケーションのバージョン番号が記述される「親アプリケーションバージョン番号」の項目とを有している。

〈バージョン対応テーブルＴ７〉
バージョン対応テーブルＴ７は、モジュールバージョン番号とアプリケーションバージョン番号との対応関係（すなわち、アプリケーションバージョンと当該アプリケーションバージョンに含まれるモジュールバージョンとの対応関係）を示すテーブルである。例えば図５（ｃ）に示される例によると、モジュールバージョン番号「Ｍ１」が、アプリケーションバージョン番号「Ａ１」に含まれることがわかる。

再び図２を参照する。ソフトウェア条件合致装置抽出部１５０は、障害の要因となるバージョンのモジュールや機能要求を出すバージョンのモジュールが含まれるアプリケーションバージョンがインストールされた半導体製造装置２を抽出する。より具体的には、管理対象となる半導体製造装置２の中から、要求・障害に係るアプリケーションソフトウェアがインストールされた装置を抽出する。つまり、ここで抽出された半導体製造装置２は、ソフトウェア条件からみて障害が発生する可能性のある装置（もしくは機能要求に係る装置）ということになる。

ハードウェア条件合致装置抽出部１６０は、障害が発生しうるハードウェア条件の半導体製造装置２を抽出する。より具体的には、管理対象となる半導体製造装置２の中から、障害が発生するハードウェア条件に合致する装置を抽出する。つまり、ここで抽出された半導体製造装置２は、ハードウェア条件からみて障害が発生する可能性のある装置ということになる。

また、ハードウェア条件合致装置抽出部１６０は、ソフトウェアからの機能要求を充足するハードウェア条件の半導体製造装置２を抽出する。より具体的には、管理対象となる半導体製造装置２の中から、ソフトウェアが正常に機能するためのハードウェア条件に合致する装置を抽出する。つまり、ここで抽出された半導体製造装置２は、ハードウェア条件からみて機能要求を充足する装置ということになる。

〈２．処理〉
障害の影響する装置を特定する処理およびソフトウェアからの機能要求を充足する装置を特定する処理について説明する。

なお、以下に説明する処理が実行される前提として、ソフトウェア情報取得部１１０が、管理対象の半導体製造装置２のインストール履歴情報を取得しており、各装置のインストール履歴情報が蓄積されたインストール履歴テーブルＴ１が記憶部１２に格納されているものとする。

また、ハードウェア情報取得部１２０が、管理対象の半導体製造装置２のハードウェア構成に関する更新情報を取得しており、各装置のハードウェア情報が蓄積されたハードウェア詳細情報テーブルＴ２が記憶部１２に格納されているものとする。

さらに、障害・要求情報取得部１３０が、障害や機能要求に関する情報を取得しており、各障害・要求のハードウェア条件が障害・要求番号とともに蓄積された障害・要求テーブルＴ３が記憶部１２に格納されているものとする。

またさらに、モジュールバージョンテーブルＴ５と、アプリケーションバージョンテーブルＴ６と、バージョン対応テーブルＴ７とが記憶部１２に格納されているとする。

〈２−１．障害の影響範囲を特定する処理〉
図６は、障害の影響を受けるハードウェアを特定する処理の流れを示す図である。

まず、調査対象となる障害（以下において「調査対象障害」という。）を特定する（ステップＳ１）。調査対象障害の特定は、オペレータに操作部１３から調査を所望する障害の障害番号を入力させるとともに、当該入力された障害番号を受け付けることによって行われる。また、障害テーブルＴ３ａに新たな障害が格納された場合に、当該新たに格納された障害が自動的に調査対象と特定される構成としてもよい。

続いて、アプリケーションバージョン特定部１４０が、調査対象障害に係るアプリケーションバージョン番号を特定する（ステップＳ２）。

ステップＳ２の処理について、図７を参照しながらより具体的に説明する。図７は、ステップＳ２の処理の流れを示す図である。

はじめに、障害・要求テーブルＴ３を参照して、調査対象障害に係るモジュールバージョン番号を取得する（ステップＳ１１）。より具体的には、障害テーブルＴ３ａを参照して、調査対象障害の障害混入モジュールバージョン番号と障害修正モジュールバージョン番号とを取得する。

続いて、モジュールバージョンテーブルＴ５に格納されたモジュールバージョンを１つ取り出して、当該モジュールバージョンが調査対象障害を含むか否かを判断する（ステップＳ１２）。より具体的には、取り出したモジュールバージョンが、ステップＳ１１で取得した障害混入モジュールバージョン以降かつ障害修正モジュールバージョンより前である場合には、当該モジュールバージョンが障害を含むと判断する。なお、モジュールバージョンテーブルＴ５に格納されたモジュールバージョンを、モジュールバージョンの親子関係をたどる形で取り出すことが望ましい。これによって効率的にステップＳ１２の判断処理を行うことが可能となる。

ステップＳ１２において、取り出したモジュールバージョンが調査対象障害を含まないと判断された場合、モジュールバージョンテーブルＴ５に格納されたモジュールバージョンの全てについてステップＳ１２の判断が行われたか否かを判断する（ステップＳ１３）。

ステップＳ１３において、ステップＳ１２の判断が行われていないモジュールバージョンが残っていると判断された場合は、再びステップＳ１２に戻り、別のモジュールバージョンを取り出してステップＳ１２の判断処理を行う。

ステップＳ１２において、取り出したモジュールバージョンが調査対象障害を含むと判断された場合、続いて、アプリケーションバージョンテーブルＴ６に格納されたアプリケーションバージョンを１つ取り出して、当該アプリケーションバージョンが調査対象障害を含むか否かを判断する（ステップＳ１４）。より具体的には、取り出したアプリケーションバージョンにステップＳ１２で調査対象障害を含むと判断されたモジュールバージョンが含まれるか否かを判断する。この判断は、さらに具体的には次のように行われる。まず、取り出したアプリケーションバージョンに含まれるモジュールバージョンをバージョン対応テーブルＴ７を参照して特定する。続いて当該特定されたモジュールバージョンの中にステップＳ１２で調査対象障害を含むと判断されたモジュールバージョンが含まれるか否かを判断する。なお、アプリケーションバージョンテーブルＴ６に格納されたアプリケーションバージョンを、アプリケーションバージョンの親子関係をたどる形で取り出すことが望ましい。これによって効率的にステップＳ１４の判断処理を行うことが可能となる。

ステップＳ１４において、取り出したアプリケーションバージョンが調査対象障害を含むと判断された場合、当該アプリケーションバージョンのアプリケーションバージョン番号を調査対象障害に係るアプリケーションバージョン番号として記憶する（ステップＳ１５）。ステップＳ１５の処理が終了すると、ステップＳ１６の処理に進む。

ステップＳ１４において、取り出したアプリケーションバージョンが調査対象障害を含まないと判断された場合は、ステップＳ１５の処理を行うことなくステップＳ１６の処理に進む。

ステップＳ１６においては、アプリケーションバージョンテーブルＴ６に格納されたアプリケーションバージョンの全てについてステップＳ１４の判断が行われたか否かを判断する。

ステップＳ１６において、全アプリケーションバージョンについてステップＳ１４の判断が行われたと判断された場合は、ステップＳ１３の処理に進む。一方、ステップＳ１６において、ステップＳ１４の判断が行われていないアプリケーションバージョンが残っていると判断された場合は、再びステップＳ１４に戻り、別のアプリケーションバージョンを取り出してステップＳ１４の判断処理を行う。

ステップＳ１３において、全モジュールバージョンについてステップＳ１２の判断が行われたと判断された場合は、処理を終了する。

以上の処理によって、調査対象障害に係るアプリケーションバージョン番号がもれなく特定される。

再び図６を参照する。ステップＳ２において、調査対象障害に係るアプリケーション（以下において「調査対象アプリケーション」という。）のアプリケーションバージョン番号が特定されると、続いて、ソフトウェア条件合致装置抽出部１５０が、管理対象の半導体製造装置２の１つを判定対象の装置として取り出して、当該装置が、調査対象アプリケーションがインストールされた装置（以下において「ソフトウェア条件合致装置」という。）であるか否かを判断する（ステップＳ３）。より具体的には、まず、判定対象の装置に現在インストールされているアプリケーションソフトウェアのアプリケーションバージョン番号をインストール履歴テーブルＴ１から取得する。続いて、当該取得したアプリケーションバージョン番号が、ステップＳ３で特定されたアプリケーション番号（すなわち、調査対象アプリケーションのアプリケーションバージョン番号）と一致するか否かを判断し、一致する場合には当該判定対象の装置をソフトウェア条件合致装置と判断する。

ステップＳ３において、判定対象の装置がソフトウェア条件合致装置でないと判断された場合、当該装置はソフトウェア条件からみて障害の影響を受けない装置であると判断する。この場合、当該装置についての判定処理は終了してステップＳ６の処理に進む。

ステップＳ３において、判定対象の装置がソフトウェア条件合致装置である判断された場合、続いて、ハードウェア条件合致装置抽出部１６０が、当該装置が調査対象障害のハードウェア条件に合致する装置（以下において「ハードウェア条件合致装置」という。）であるか否かを判断する（ステップＳ４）。

ステップＳ４の処理について、図８を参照しながらより具体的に説明する。図８は、ステップＳ４の処理の流れを示す図である。

まず、調査対象障害のハードウェア条件番号を障害・要求テーブルＴ３から取得するとともに、当該ハードウェア条件番号に係るリソースおよびリソース値と比較演算子をハードウェア条件テーブルＴ４から取得する（ステップＳ２１）。

続いて、ハードウェア詳細情報テーブルＴ２を参照して、判定対象の装置のリソース値（より具体的には、ステップＳ２１で取得したリソースのリソース値）を取得する（ステップＳ２２）。

続いて、ステップＳ２２で取得した判定対象装置のリソース値が、ステップＳ２１で取得したハードウェア条件のリソース値との関係において、ステップＳ２１で取得した比較演算子が規定する条件を充足するか否かを判断する（ステップＳ２３）。

ステップＳ２３において、比較演算子が規定する条件を充足すると判断された場合には判定対象の装置がハードウェア条件合致装置であると判断し（ステップＳ２４）、充足しないと判断された場合には判定対象の装置がハードウェア条件合致装置ではないと判断する（ステップＳ２５）。

以上の処理によって、判定対象の装置がハードウェア条件合致装置であるか否かが判断される。

再び図６を参照する。ステップＳ４において、判定対象の装置がハードウェア条件合致装置であると判断された場合、当該装置はソフトウェア条件とハードウェア条件の両方を充足する装置であり、障害の影響を受ける装置（以下において「障害該当装置」という。）であると判断する。この場合、図示しないリスト作成部が、当該判定対象の装置のシリアル番号を取得して、リストに追加する（ステップＳ５）。つまり、これによって調査対象障害の障害該当装置のリストが作成されることになる。ステップＳ５の処理が終了すると、ステップＳ６の処理に進む。

ステップＳ４において、判定対象の装置がハードウェア条件合致装置でないと判断された場合、当該装置はハードウェア条件からみて障害の影響を受けない装置であると判断する。この場合、当該装置についての判定処理は終了してステップＳ６の処理に進む。

ステップＳ６においては、管理対象となる半導体製造装置２の全てに対してステップＳ３の判断処理を行ったか否かを判断する。管理対象となる半導体製造装置２の中でステップＳ３の判断処理が行われていない装置が残っていると判断された場合、再びステップＳ３の処理に戻り、判断処理が行われていない別の装置を取り出してステップＳ３の判断処理を行う。管理対象となる全ての半導体製造装置２に対してステップＳ３の判断処理が終了したと判断された場合、処理を終了する。

以上の処理によって、調査対象障害が影響するハードウェアが特定される。

〈２−２．機能要求を充足するハードウェアを特定する処理〉
図９は、ソフトウェアからの機能要求を充足するハードウェアを特定する処理の流れを示す図である。

まず、調査対象となる要求（以下において「調査対象要求」という。）を特定する（ステップＳ３１）。調査対象要求の特定は、オペレータに操作部１３から要求テーブルＴ３ｂの要求番号を入力させるとともに、当該入力された要求番号を受け付けることによって行われる。また、要求テーブルＴ３ｂに新たな要求が格納された場合に、当該新たに格納された要求が自動的に調査対象と特定される構成としてもよい。

続いて、アプリケーションバージョン特定部１４０が、調査対象要求に係るアプリケーションバージョン番号を特定する（ステップＳ３２）。ステップＳ３２の処理は、ステップＳ２（図６）と同様の処理である。ただし、ステップＳ３２においては、ステップＳ１１（図７）に相当する処理として、要求テーブルＴ３ｂを参照して調査対象要求に係るモジュールバージョン番号として調査対象要求の対応モジュールバージョン番号を取得する。また、ステップＳ１２（図７）に相当する処理として、モジュールバージョンテーブルＴ５に格納されたモジュールバージョンのそれぞれが、調査対象要求を含むか否か（より具体的には、調査対象要求の対応モジュールバージョン番号を含むか否か）を判断する。

ステップＳ３２において、調査対象要求に係るアプリケーション（調査対象アプリケーションバージョン）のアプリケーションバージョン番号が特定されると、続いて、ソフトウェア条件合致装置抽出部１５０が、管理対象の半導体製造装置２の１つを判定対象の装置として取り出して、当該装置が、調査対象アプリケーションがインストールされた装置（ソフトウェア条件合致装置）であるか否かを判断する（ステップＳ３３）。この処理はステップＳ３（図６）と同様である。

ステップＳ３３において、判定対象の装置がソフトウェア条件合致装置でないと判断された場合、当該装置はソフトウェア条件からみて機能要求に係る装置ではないと判断する。この場合、当該装置についての判定処理は終了してステップＳ３６の処理に進む。

ステップＳ３３において、判定対象の装置がソフトウェア条件合致装置であると判断された場合、続いて、ハードウェア条件合致装置抽出部１６０が、当該装置が、調査対象要求のハードウェア条件に合致する装置（ハードウェア条件合致装置）であるか否かを判断する（ステップＳ３４）。この処理はステップＳ４（図６）と同様である。

ステップＳ３４において、判定対象の装置がハードウェア条件合致装置であると判断された場合、当該装置はソフトウェア条件からみて機能要求に係る装置でありかつ要求されるハードウェア条件を充足する装置（以下において「要求充足装置」という。）であると判断する。この場合、図示しないリスト作成部が、当該判定対象の装置のシリアル番号を取得して、リストに追加する（ステップＳ３５）。つまり、これによって要求充足装置のリストが作成されることになる。ステップＳ３５の処理が終了すると、ステップＳ３６の処理に進む。

ステップＳ３４において、判定対象の装置がハードウェア条件合致装置でないと判断された場合、当該装置は要求されるハードウェア条件を充足しない装置であると判断する。この場合、当該装置についての判定処理は終了してステップＳ３６の処理に進む。なお、ここで、図示しないリスト作成部が、当該判定対象の装置のシリアル番号を取得して、リストに追加する構成としてもよい。この場合、機能要求を出したソフトウェアがインストールされているにも拘わらず、当該機能要求を充足しない装置のリストが得られることになる。

ステップＳ３６においては、管理対象となる半導体製造装置２の全てに対してステップＳ３３の判断処理を行ったか否かを判断する。この処理はステップＳ６（図６）と同様である。管理対象となる全ての半導体製造装置２に対してステップＳ３３の判断処理が終了したと判断された場合、処理を終了する。

以上の処理によって、調査対象機能を充足するハードウェアが特定される。

〈効果〉
上記の実施の形態に係るトレーサビリティ管理装置１においては、管理対象の半導体製造装置２のハードウェア構成に変更・追加がなされた場合に、その更新情報を取得する手段（ハードウェア情報取得部１２０）を備えている。したがって、管理対象となる半導体製造装置２のハードウェアに変更・追加が行われることによって、型番と実際のリソース値とにずれが生じた場合であっても、変更・追加後の実際のリソース値をハードウェア情報として保有することができる。つまり、ハードウェアに変更や追加が行われた場合であっても、管理対象装置とのトレーサビリティを確実に確保することができる。

また、ソフトウェア上の障害の影響を受ける装置を特定する際には、まずソフトウェア条件合致装置抽出部１５０がソフトウェア条件合致装置を抽出し、ハードウェア条件合致装置抽出部１６０がソフトウェア条件合致装置の中からさらにハードウェア条件合致装置を抽出する。すなわち、ソフトウェア条件とハードウェア条件の両方を充足する装置を、障害の影響を受ける装置と判断する。これによって、ハードウェア条件に依存する障害の影響範囲を効率的かつ正確に特定することができる。その結果、障害に起因して生じる被害を食い止めるために打つべき措置を迅速に講じることが可能となり、被害を最小限に食い止めることができる。

また、ソフトウェアからの機能要求を充足する装置を特定する際にも、まずソフトウェア条件合致装置抽出部１５０がソフトウェア条件合致装置を抽出し、ハードウェア条件合致装置抽出部１６０がソフトウェア条件合致装置の中からさらにハードウェア条件合致装置を抽出する。すなわち、ソフトウェア条件とハードウェア条件の両方を充足する装置を、ソフトウェアからの機能要求を充足する装置と判断する。これによって、ソフトウェアからの機能要求を充足可能範囲を効率的かつ正確に特定することができる。

〈変形例〉
上記の実施の形態に係るトレーサビリティ管理装置１が管理対象としていたコンピュータ装置は半導体製造装置２であったが、トレーサビリティ管理装置１は、半導体製造装置２に限らず、各種のコンピュータ装置を管理対象とすることができる。特に、変更もしくは追加可能なハードウェア要素を備え、型番と実際のリソース値とにずれが生じる可能性のあるコンピュータ装置のトレーサビリティの管理において有効である。また、管理対象装置のアップデート管理が通信回線を介して行われているコンピュータ装置のトレーサビリティの管理にも有効である。具体的な例としては、半導体製造装置の他に、パーソナルコンピュータ、ＤＶＤレコーダー、携帯電話、各種情報家電等を管理対象とすることができる。

また、上記の実施の形態においては、ソフトウェア条件合致装置を抽出した後に（図６のステップＳ３）、抽出されたソフトウェア条件合致装置の中からハードウェア条件合致装置を抽出する（図６のステップＳ４）構成としていたが、ハードウェア条件合致装置を抽出した後に、抽出されたハードウェア条件合致装置の中からソフトウェア条件合致装置を抽出する構成としてもよい。

また、上記の実施の形態においては、トレーサビリティ管理装置１が管理対象の半導体製造装置２のそれぞれとネットワークＮを介して接続されているとしたが、トレーサビリティ管理装置１は管理対象の半導体製造装置２のそれぞれとネットワークＮを介して接続されていなくてもよい。この場合、ソフトウェア情報取得部１１０やハードウェア情報取得部１２０は、各半導体製造装置２のソフトウェアやハードウェアに関する情報を、ネットワークＮを介して接続された各種の通信端末装置等から取得してもよいし、可搬性の記録媒体Ｍ（例えば、ＭＯ（光磁気ディスク）やＣＤ−Ｒ／ＲＷなど）を介して取得してもよい。例えば、半導体製造装置２においてソフトウェアやハードウェアの変更等が生じた場合には、当該変更に係る情報を、電子メールなどでトレーサビリティ管理装置１に通知するようにオペレータに義務づけておいてもよい。

また、上記の実施の形態に係るトレーサビリティ管理装置１は、障害の影響を受ける装置としてリストにあげられた半導体製造装置２に対して、所定の警告メッセージなどを通知する手段をさらに備えてもよい。

また、上記の実施の形態に係るトレーサビリティ管理装置１は、調査対象障害を回避・解消するために行うべき措置（例えば、リソースの交換、ソフトウェアのバージョンアップなど）を、障害該当リストに加えられた半導体製造装置２に対して教示する（もしくは強制的に実行させる）手段をさらに備えてもよい。

この発明の実施の形態に係るトレーサビリティ管理装置の１態様であるトレーサビリティ管理装置の構成を示す図である。 障害・要求のトレーサビリティ機能に関する構成を説明する図である。 インストール履歴テーブルおよびハードウェア詳細情報テーブルの構成例を示す図である。 障害テーブル、要求テーブルおよびハードウェア条件テーブルの構成例を示す図である。 モジュールバージョンテーブル、アプリケーションバージョンテーブルおよびバージョン対応テーブルの構成例を示す図である。 障害の影響を受けるハードウェアを特定する処理の流れを示す図である。 調査対象障害に係るアプリケーションバージョン番号を特定する処理の流れを示す図である。 判定対象の装置がハードウェア条件合致装置であるか否かを判断する処理の流れを示す図である。 ソフトウェアからの機能要求を充足するハードウェアを特定する処理の流れを示す図である。

符号の説明

１ トレーサビリティ管理装置
２ 半導体製造装置
１１０ ソフトウェア情報取得部
１２０ ハードウェア情報取得部
１３０ 障害・要求情報取得部
１４０ アプリケーションバージョン特定部
１５０ ソフトウェア条件合致装置抽出部
１６０ ハードウェア条件合致装置抽出部
Ｐ プログラム

Claims (5)

1. 変更もしくは追加可能なハードウェア要素を備える複数のコンピュータ装置のトレーサビリティを提供するトレーサビリティ管理装置において、
   前記複数のコンピュータ装置それぞれのインストール履歴を取得するソフトウェア情報取得手段と、
   前記複数のコンピュータ装置それぞれの前記ハードウェア要素に関する更新情報を取得するハードウェア情報取得手段と、
   ソフトウェア上の障害の影響範囲をトレースするにあたって、前記複数のコンピュータ装置の中から前記障害を含むソフトウェアがインストールされた装置を抽出する第１の装置抽出手段と、
   前記複数のコンピュータ装置の中から前記障害が発生するハードウェア条件を充足する装置を抽出する第２の装置抽出手段と、
   を備え、
   前記複数のコンピュータ装置の中で、前記第１の装置抽出手段で抽出されかつ前記第２の装置抽出手段で抽出された装置を障害該当コンピュータ装置に特定することを特徴とするトレーサビリティ管理装置。
2. 変更もしくは追加可能なハードウェア要素を備える複数のコンピュータ装置のトレーサビリティを提供するトレーサビリティ管理装置において、
   前記複数のコンピュータ装置それぞれのインストール履歴を取得するソフトウェア情報取得手段と、
   前記複数のコンピュータ装置それぞれの前記ハードウェア要素に関する更新情報を取得するハードウェア情報取得手段と、
   ソフトウェアからの機能要求を充足する範囲をトレースするにあたって、前記複数のコンピュータ装置の中から前記機能要求に係るソフトウェアがインストールされた装置を抽出する第１の装置抽出手段と、
   前記複数のコンピュータ装置の中から前記ソフトウェアから要求されるハードウェア条件を充足する装置を抽出する第２の装置抽出手段と、
   を備え、
   前記複数のコンピュータ装置の中で、前記第１の装置抽出手段で抽出されかつ前記第２の装置抽出手段で抽出された装置を要求充足コンピュータ装置に特定することを特徴とするトレーサビリティ管理装置。
3. コンピュータのＣＰＵとメモリを利用して、請求項１または請求項２に記載のトレーサビリティ管理装置として機能させるためのプログラム。
4. 変更もしくは追加可能なハードウェア要素を備える複数のコンピュータ装置にインストールされるソフトウェア上の障害のトレース方法において、
   前記複数のコンピュータ装置それぞれのインストール履歴を取得するソフトウェア情報取得工程と、
   前記複数のコンピュータ装置それぞれの前記ハードウェア要素に関する更新情報を取得するハードウェア情報取得工程と、
   前記複数のコンピュータ装置の中から前記障害を含むソフトウェアがインストールされた装置を抽出する第１の装置抽出工程と、
   前記第１の装置抽出工程で抽出された装置の中から、前記障害が発生するハードウェア条件を充足する装置を抽出する第２の装置抽出工程と、
   を備えることを特徴とするトレース方法。
5. 変更もしくは追加可能なハードウェア要素を備える複数のコンピュータ装置にインストールされるソフトウェアからの機能要求のトレース方法において、
   前記複数のコンピュータ装置それぞれのインストール履歴を取得するソフトウェア情報取得工程と、
   前記複数のコンピュータ装置それぞれの前記ハードウェア要素に関する更新情報を取得するハードウェア情報取得工程と、
   前記複数のコンピュータ装置の中から前記機能要求に係るソフトウェアがインストールされた装置を抽出する第１の装置抽出工程と、
   前記第１の装置抽出工程で抽出された装置の中から、前記ソフトウェアから要求されるハードウェア条件を充足する装置を抽出する第２の装置抽出工程と、
   を備えることを特徴とするトレース方法。

Images