(57)【要約】【課題】技術設備で故障した機能ユニットを迅速かつ正確に特定できるようにする。【解決手段】複数の機能ユニット（９）を有する技術設備（３）内で故障した機能ユニット（１７）の特定を支援するために、第１のテストを技術設備で行い、技術設備内で測定を行って第１のテスト結果（５）を供給し、どの機能ユニットをテストしたかに関する情報を纏めたテストモデルを用いて、かつ技術設備がどのような構造を有しているかに関する情報を纏めたシステムモデル（３１）を用いて、第１のテスト結果の自動的な処理を行い、故障している可能性がある機能ユニットの群を決定するために第１のテスト結果を分析し、該分析を参考にしつつ群の各機能ユニットに故障確率（１５）を割り当てる。【選択図】　図１
2004118839.tif 000002
【特許請求の範囲】
【請求項１】
　技術設備（３）内で故障した機能ユニット（１７）の特定を支援する方法において、
　この技術設備は複数の機能ユニット（９）を有しており、
　特定をするために第１のテストを技術設備（３）内で行い、
　第１のテストは技術設備（３）内での測定を行って第１のテスト結果（５）を供給し、
　どの機能ユニット（９）をテストしたかに関する情報を纏めたテストモデル（６３）を用いて、かつ技術設備（３）がどのような構造を有しているかに関する情報を纏めたシステムモデル（３１）を用いて、
　次のような特徴を備える第１のテスト結果（５）の自動的な処理を行う方法。
　故障している可能性がある機能ユニット（９）の群を決定するために第１のテスト結果（５）を分析し、次いで
　該分析を参考にしつつ群の各機能ユニット（９）に故障確率（１５）を割り当てる。
【請求項２】
　ある機能ユニット（９）の故障確率（１５）が有意な限界故障確率を上回っている場合には、この機能ユニット（９）が故障であると特定する請求項１記載の方法。
【請求項３】
　どの故障確率（１５）も有意な限界を上回っていない場合には、故障確率（１５）を参考にして、群の機能ユニット（９）の故障確率（１５）を精密化するために少なくとも１つの第２のテストを提案する請求項１記載の方法。
【請求項４】
　テスト提案（１９）を、故障している機能ユニット（１７）の特定に関わるテスト提案（１９）の重要性を判定する少なくとも１つの基準に基づき自動的に配列する請求項３記載の方法。
【請求項５】
　提案されたテストのうち最も重要なテストを自動的に実施する請求項４記載の方法。
【請求項６】
　第２のテストを実施し、
　第１のテスト結果（５）を考慮した上で、かつテストモデルに準じてどの機能ユニット（９）をテストしているか、システムモデルに準じて技術設備（３）がどのような構造を有しているか、少なくとも１つの以前のテストがどのような結果を供給しているかに関する情報を取り入れた上で、
　群の機能ユニット（９）の故障確率（１５）を精密化するために第２のテスト結果（２１）を分析し、
　ある機能ユニット（９）の精密化された故障確率（１５）が有意な限界を上回っている場合には、この機能ユニット（９）が故障であると特定し、
　どの故障確率（１５）も有意な限界を上回っていない場合には、故障確率（１５）を参考にしながら、群の機能ユニット（９）の故障確率（１５）を精密化するために少なくとも１つの次のテストを提案し、このテスト提案（１９）は、故障している機能ユニット（１７）の特定に関わるテスト提案（１９）の重要性を判定する少なくとも１つの基準に基づいて自動的に配列する請求項３から５の１つに記載の方法。
【請求項７】
　ある機能ユニット（９）の故障確率（１５）が有意な限界故障確率を上回り、この機能ユニット（９）が故障として特定される迄、新たに提案されたテストを各々実施する請求項５又は６記載の方法。
【請求項８】
　テストを実施した後の機能ユニット（９）の故障確率を、テスト前の故障確率（１５）と、テストに基づく故障確率（１５）との数学的な組み合わせから求める請求項１から７迄の１つに記載の方法。
【請求項９】
　故障確率（１５）の組み合わせをベイズのネットワークモデルを用いて行う請求項８記載の方法。
【請求項１０】
　機能ユニット（９）が交換可能なモジュールである請求項１から９の１つに記載の方法。
【請求項１１】
　機能ユニット（９）が他の機能ユニット（９）の間の接続ユニットである請求項１から１０の１つに記載の方法。
【請求項１２】
　前記接続ユニットが他の機能ユニット（９）の間で電気信号又は光学信号を伝送する請求項１から１１の１つに記載の方法。
【請求項１３】
　前記接続ユニットが他の機能ユニット（９）にエネルギー供給をする役目を果たす請求項１から１２の１つに記載の方法。
【請求項１４】
　テストが個々の機能ユニット（９）の機能をチェックする請求項１から１３の１つに記載の方法。
【請求項１５】
　テストがテスト信号経路に沿って複数の機能ユニット（９）をチェックする請求項１から１４の１つに記載の方法。
【請求項１６】
　テストプログラム（４１）からパラメータ化によって種々のテストを生成する請求項１から１５の１つに記載の方法。
【請求項１７】
　共通の役割をもつ複数のテストが１つのテストブロック（５１）を形成し、実施を簡素化するために、テストブロック（５１）のただ１回の呼び出しによって実施する請求項１から１６の１つに記載の方法。
【請求項１８】
　どの機能ユニット（９）をテスト又はテストブロック（５１）でチェックするかに関する情報をテストモデル（６３）に纏めた請求項１から１７の１つに記載の方法。
【請求項１９】
　テストモデル（６３）を、技術設備（３）に合わせてテストプログラムモデル（６５）をコンフィギュレーションすることにより生成し、このテストプログラムモデル（６５）が、技術設備（３）又はこの技術設備に類似する設備で実行可能なテスト又はテストブロック（５１）の記述を含んでいる請求項１８記載の方法。
【請求項２０】
　テスト又はテストブロック（５１）の記述が、役割と、重要なパラメータと、各々該当する機能ユニット（９）とを記述している請求項１９記載の方法。
【請求項２１】
　システムモデル（３１）が機能ユニット（９）を基礎としている請求項１から２０の１つに記載の方法。
【請求項２２】
　システムモデル（３１）を、技術設備（３）に合わせてスーパシステムモデル（３３）をコンフィギュレーションすることで生成し、該スーパシステムモデル（３３）では、使用する技術設備（３）を模式化した状態で表現している請求項２１記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
　本発明は、技術設備内で故障した機能ユニットの特定を支援する方法に関する。
【背景技術】
【０００２】
　技術設備内で故障した機能ユニットを特定することは、迅速かつ有効な修理のための前提条件である。多くの場合、故障した機能ユニットだけを、完全な代替機能ユニットと交換する。迅速な修理は停止時間の短縮につながり、その結果技術設備の実効性を高める。
【０００３】
　互いに独立した多数の機能ユニットで構成される技術設備の複雑さは、特定を困難にし技術設備で多種多様な測定を行う多くのテストを必要とする。正しいテストの選択、テストの組み合わせおよびテストの判定はサービス技術者の役目であり、そのためにサービス技術者には、例えばハンドブック、回路図、テストに関する情報といった支援情報が与えられる。こうした支援情報やテストは絶えず更新され、技術設備の改良発展に合わせて適合化されるので、サービス技術者が持っている情報の水準は古くなってしまい易く、そのために、設備全体を検査しなければ故障した機能ユニットを特定できないことになる。故障していない機能ユニットの不必要な交換をする度に、余分のコストが発生する。
【０００４】
　特許文献１より、開発すべき技術的な装置、設備又はシステムの検査仕様書をコンピュータ支援で最適化し、検査ソフトウェアを最低限に抑え、検査可能性を検証する方法が公知である。この場合、まず技術コンセプトに応じて製品モデルが作成、入力され、このモデルを記述するコンポーネントは、機能ブロック或いは最小および最大の交換可能なユニット、各機能ブロックの間のテストパスとなる接続部、各機能ブロック間や内部に設けるべき診断テストポイント等である。次のステップで、製品モデルの機能面の深さのアダプティブな調節が、先行するモデル段階で得られている検査可能性情報に依存して行われ、そのためコンピュータを用いてテストパスがシミュレーションされ、得られたテストレポートが検査ロジックにより評価される。かくして、場合により複数のステップで得られる完全に検査可能な最適化された製品モデルが、技術データバンクに保存され、各テストパスの名称を経て、標準化された検査ソフトウェアへのプログラム側の接続を成立させる。
【０００５】
　特許文献２より、電気設備へのインターフェースを有する計算設備を用いて、技術プロセスの制御および／又は監視をするためのおよび／又は工業オートメーション化および／又は建物オートメーション化のための、モジュール形式の電気機器／電気ステーションからなる電気設備の設計・診断装置が公知である。
【特許文献１】独国特許出願公開第１９８０３０３２明細書
【特許文献２】独国特許第１９９１７１０２明細書
【発明の開示】
【発明が解決しようとする課題】
【０００６】
　本発明の課題は、技術設備内で故障した機能ユニットを迅速かつ正確に特定できるようにすることである。
【課題を解決するための手段】
【０００７】
　この課題は本発明によれば、複数の機能ユニットを有する技術設備内で故障した機能ユニットの特定を支援する方法であって、特定のために第１のテストを技術設備内で行い、第１のテストは技術設備内での測定を経て第１のテスト結果を供給し、どの機能ユニットをテストしたかに関する情報を纏めたテストモデルを用いて、および技術設備がどのような構造を有しているかに関する情報を纏めたシステムモデルを用いて、第１のテスト結果の自動的な処理を行い、故障している可能性がある機能ユニットの群を決定するために第１のテスト結果を分析し、この分析を参考にしながら群の各機能ユニットに故障確率を割り当てる方法によって解決される。
【０００８】
　この方法の利点は、技術設備の構造に関するシステムモデルの情報を、技術設備で行う第１のテストと組み合わせ得る点にある。その結果、第１のテストでどの機能ユニットをテストしたかに関する情報を、方法の中で援用できる。そしてこのことは、技術設備を構成する全ての機能ユニットから１群の機能ユニットを選び出す、第１のテスト結果の自動的な処理を可能にする。
【０００９】
　この群の機能ユニットは、これらユニットのうち少なくとも１つが故障しているという特徴を備えている。２つの極端なケースを使って、テスト結果に依存する機能ユニットの割当について説明すると、テストした機能ユニットの１つが故障していることをテストが示唆している第１の事例では、テストした機能ユニットによって群が構成される。第２の事例では、テストした機能ユニットの故障をテストが示唆しておらず、テストした機能ユニットは群に割り当てられない。
【００１０】
　本方法の更に別の利点は、群の各機能ユニットに、第１のテストへの関与によって判明した故障確率を割り当てるために、技術設備に関する情報を援用できることである。このとき、例えば機能ユニットの故障し易さといった、テストモデルの追加情報を割当に取り入れることもできる。かくして、より正確な故障確率の割り当てが可能となる。
【００１１】
　本発明の発展例では、群に含まれる各機能ユニットの故障確率を、有意な限界故障確率と比較し、この限界故障確率は、限界故障確率よりも大きい各々の故障確率が、これに帰属する機能ユニットを故障として分類することで定義される。このことは、故障確率の自動的な分析と割当により、故障している機能ユニットを特定できる利点がある。
【００１２】
　有意な限界故障確率を上回る故障確率がまだ出ていない場合を対象とする本発明の発展例では、故障確率を参考にしつつ少なくとも１つの第２のテストを提案し、このテストは故障確率を一層精密化する役割を果たす。このことは、例えば機能ユニットの群のサブ群だけをテストすることで実現できる。この方法の利点は、故障確率を利用しつつ、同時に技術設備の構造に関する情報と、どの機能ユニットにどのテストを行うかに関する情報とを用いて、テストを自動化すると共に、そのテストの実施が、群の各機能ユニットの故障確率の一層の精密化をどの程度迄可能にするかを判定できる点にある。
【００１３】
　本方法の発展例では、故障したユニットの特定に関するテスト提案の重要性を判断する少なくとも１つの基準に基づき、テスト提案を自動的に配列する。例えば、テストの進行中に必要とする時間コストも考慮に含めるのが好ましいであろう。或いは、テストに関与した機能ユニットが、故障確率の特別な精密化をするのが好ましい機能ユニットとどの程度一致しているかに関する判定が可能であろう。
【００１４】
　１つの発展例では、提案したテストの内で最重要のテストを自動的に実施する。このことは、サービス技術者の介入に関わりなく、一連のテストを行える利点がある。
【００１５】
　格別に有利な実施形態では、第２のテストとして、テスト提案の内の１つを実施する。そして第１のテスト結果を考慮した上で、かつ、テストモデルに準じてどの機能ユニットをテストしたかに関する情報と、システムモデルに準じて技術設備がどのような構造を有しているかに関する情報と、少なくとも１つの以前のテストがどのような結果を供給したかに関する情報とを加味した上で、群の各機能ユニットの故障確率を一層精密化するために第２のテストのテスト結果を分析する。更に、ある機能ユニットの精密化した故障確率が有意な限界を上回っていれば、その機能ユニットが故障していると特定し、どの故障確率も有意な限界を上回っていないなら、群の各機能ユニットの故障確率を精密化すべく更に別のテストを提案する。これに加えて、このテスト提案を、故障したユニットの特定に関するテスト提案の重要性を判定する少なくとも１つの基準に基づき自動的に配列する。
【００１６】
　本方法の発展例では、１つの機能ユニットの故障確率が有意な限界を上回る迄、各々新たに提案されるテストを実施し、該機能ユニットを故障した機能ユニットとして特定する。この発展例の利点は、テスト結果の自動的な処理を反復して実施するので、故障の可能性がある機能ユニットの群の絞り込みが可能な点にあり、故障している機能ユニットが特定される迄、かかる絞り込みをサービス技術者の協力作業なしに継続できる。この方法の誤り率は、限界故障確率の選択により最低限に抑えることができる。
【００１７】
　特別な実施形態では、テスト実施後の機能ユニットの故障確率を、テスト前のそれと、テストに基づく故障確率との数学的な組み合わせから求める。このことは、既に得られている情報を、機能ユニットの故障確率へ的確に取り入れられる利点がある。
【００１８】
　本方法の特別に有利な実施形態では、技術設備を構成している各機能ユニットが、一方では交換可能なモジュールであり、他方では、他の機能ユニットと機能ユニットの間の交換可能な接続ユニットである。この接続ユニットは、両機能ユニット間で、例えば電気信号や光学信号のような信号を伝送する。更に、接続ユニットは油圧や空気圧の経路を経て信号を伝送し、或いは機能ユニットにエネルギーを供給する。技術施設の構成を、全体として交換可能な機能ユニットＦＲＵ（field replaceable units（現場交換可能ユニット））に分けて構造化することは、故障した機能ユニットを特定した後に、その機能ユニットの交換により技術設備の修理を迅速に行える利点に結び付く。従って、機能ユニットを例えば技術設備のＦＲＵに関連付けるのが好ましい。
【００１９】
　本方法の有利な実施形態では、各機能ユニットの機能をチェックするテストを含む。別の実施形態では、テスト信号経路に沿う複数の機能ユニットをチェックする。これら実施形態は、一方では、個々の機能ユニットをチェックでき、他方では、複数の機能ユニットの連係をチェックできる利点がある。
【００２０】
　特別に有利な実施形態では、種々のテストをテストプログラムからパラメータ化によって生成できる。このことは、テストプログラムを一般的な形態で設計できる利点があり、そしてこのテストプログラムを、例えば構成の点で類似している様々な構造をチェックするのに使える。更に別の利点は、各々の技術設備の対応するパラメータをテストプログラムに送ることで、１つのシステムファミリの種々の技術設備で進行するテストプログラムを書き込める点にある。
【００２１】
　特別に有利な実施形態では、例えば共通の役割をもつ複数のテストで１つのテストブロックを形成し、かくして、実施方法を簡素化すべく、テストブロックを１回だけ呼び出せば実行可能になる。このことは、例えば技術設備の１つのモジュールをチェックする役目の複数のテストを、該モジュールの各機能ユニットの故障確率を詳細に規定すべく、的確に呼び出せる利点がある。更に別の利点は、サービス技術者が多数の異なるテストを個々に呼び出さなくてすむ点にある。
【００２２】
　特別に有利な実施形態では、どの機能ユニットをどのテスト又はテストモデルでチェックするかを、テストモデルに纏める。テストモデルは、例えば技術設備に合わせてテストプログラムモデルをコンフィギュレーションすることで生成させる。このときテストプログラムモデルは、例えば技術設備又はこの技術設備に類似する設備で実行可能なテスト又はテストブロックを記述する。テスト又はテストブロックの記述は、その役割や、テストのためにどのような前作業と後作業が技術設備で必要か、テストを自動的に実施できるか、それともサービス技術者の協働作業が必要かといった内容を含むと共に、その他の重要なパラメータや、当然ながらテストの対象となる各機能ユニットを含んでいてよい。重要なパラメータとは、例えばテストを実施する時間である。
【００２３】
　この種テストプログラムモデルはスーパテストプログラムモデルから導出でき、テスト結果の自動的な処理のプログラミングが可能であり、該プログラミングを、技術設備のシステムファミリ全体に適用できる利点がある。更にテストプログラムモデルは、テスト結果に対する機能ユニットの機能性の依存度を含んでいてよく、或いは、経験を積んだサービス技術者、システムデザイナ、エンジニア等の知見から得られたエラー発見のための規則を、一般的な形態で、又は技術設備についての特殊な形態で有していてよい。そのようにして、自動的な処理が一種のエキスパートシステムを活用できる。
【００２４】
　このテストモデルを用いて本方法を具体化する利点は、故障特定の進行を自動化可能な点にある。そしてこの自動化は、テストモデルをテストブロックに関わりなく構築することを可能とし、本方法により故障確率の精密化につながるテストを的確に呼び出すことができる。このことは、テストモデルで関連情報を利用し、自動化した処理により可能となる。かくして故障特定を大幅に迅速化できる。テストブロックの全テストを、それが好ましいテストであろうとなかろうと、残さず実施する必要がなくなるからである。
【００２５】
　特別に有利な実施形態では、システムモデルが機能ユニットに基づいている。システムモデルは、例えば技術設備に合わせてスーパシステムモデルをコンフィギュレーションすることで生成できる。このときスーパシステムモデルは、例えば１つのシステムファミリに属し、使用される全ての技術設備を含む。このようなシステムモデルの利点は、技術設備の構造に着目したテスト又はテストブロックの解釈が可能なので、テスト又はテストブロックの対象となる機能ユニットがアクセス可能になる点にある。システムモデルは、例えばどの機能ユニット（ＦＲＵ）が技術設備に存在しているか、これらの機能ユニットが接続ユニット（ケーブル）を経てどのように相互に接続されているかを知っている。更にシステムモデルは、機能ユニットの信頼度に関する統計的なモデルを有していてよい。
【００２６】
　即ち本発明の方法による、故障した機能ユニットの特定の自動化した支援は、例えば一方では、技術設備がシステムモデルの形態で機能ユニットに分けて構造化し、他方では、テストと技術設備との相互作用をテストモデルに記述することにより具体化する。テストモデルは、例えば役割、作用範囲、必要な時間および技術設備と関連するその他の量を含んでいる。システムモデルとテストモデルのコンフィギュレーションは、各技術設備に応じて自動的に行え、本方法の進行は技術設備に関わりなくプログラミングできる。
【００２７】
　本方法の追加的な利点は、システムファミリと多数のテストを明瞭な構造で反映するテストソフトウェアに、本方法を組み込める点にある。本発明に合わせて適合化したテストソフトウェアは、システムやテストの内部における変更に関し簡単な更新を可能にする。
【００２８】
　本発明の他の有利な実施形態は、従属請求項の構成要件を備えることを特徴とする。
【発明を実施するための最良の形態】
【００２９】
　次に、図１から図１１を参照しながら、幾つかの実施例について説明する。
【００３０】
　図１は、故障した機能ユニットの特定を支援する方法のフローチャートを示す。テスト１を技術設備３内で実施し、第１のテスト結果５を供給する。第１のテスト結果５を、技術設備３の機能ユニット９をテストした情報７および技術設備３の構成に関する情報１１と共に、テスト結果５を自動的に処理するための処理ユニット１３に供給する。
【００３１】
　処理ユニット１３でテスト結果を分析し、供給された情報を考慮した上で、テスト１に基づき故障の可能性がある機能ユニット９の群をまとめる。テストが如何なる故障も示唆しないときは、例えば排除の原理に基づき、テストしていない機能ユニット９で機能ユニット９の群を形成する。テストが故障を示唆するときは、この群は、テストに関与していた機能ユニット９を含む。
【００３２】
　これに加えて分析の際、群の各機能ユニット９に故障確率１５を割り当てる。機能ユニット９の故障確率１５を限界故障確率と比較し、機能ユニット９の故障確率１５がこの限界故障確率よりも大きいと、これに帰属する機能ユニット９を直ちに故障した機能ユニット１７として特定する。限界故障確率を上回る故障確率１５がない場合、処理ユニット１３により少なくとも１つのテスト提案１９を作成する。この際テスト提案１９は、その実施により機能ユニット９の群を更に絞り込めるように選択し、或いはその実施により群の機能ユニット９の故障確率１５を精密化できるように選択する。これに応じて処理ユニット１３は機能ユニット９の故障確率１５を保存し、技術設備３の構造に関して考えられるテストの構造を機能ユニット９の群と比較し、考えられるテストが機能ユニット９の故障確率１５に及ぼす影響を見積る手段を必要とする。そのために、例えばエキスパートシステムに集められた情報や規則を補助的に取り入れることができる。
【００３３】
　更に処理ユニット１３は、テスト提案１９を、故障した機能ユニット１７の迅速かつ効率的な特定を可能にする第１のテスト提案として実施すべく、例えば同じくエキスパートシステムを用いてテスト提案１９を評価する手段を備える。そして、技術設備３の第２のテストとして最も好ましいテスト提案１９の実施を、処理ユニット１３により自動的に開始し、或いはサービス技術者に問い合わせた上で実施する。
【００３４】
　そして自動的な処理の第２のサイクルでは、処理ユニット１３は、第１のテスト１の分析に由来する情報に加えて、第２のテスト結果２１と、第２のテストでチェックした機能ユニットに関する情報とを利用する。第２のテストの実施による自動的な処理のサイクルは、故障確率１５が限界故障確率を上回る迄、即ち故障した機能ユニット１７が発見される迄、繰り返すことができる。
【００３５】
　図２は、技術設備３に合わせてコンフィギュレーションされたスーパシステム３３からシステムモデル３１が発生する様子を、模式的な図表として示す。スーパシステムモデル３３は、システムファミリの構造、即ち互いに類似する技術設備３のファミリの構造を、機能ユニット９によって記述する。ここで機能ユニット９は、ＦＲＵ３５或いはＦＲＵ３５を相互に接続する接続ユニット３７である。スーパシステムモデル３３のコンフィギュレーションにより、技術設備３の構造をシステムモデル３１に投影できる。同じくシステムファミリに属する他の技術設備についてのコンフィギュレーションは、相応のシステムモデルの発生につながる。システムモデル３１は、技術設備３で具体化された種々のＦＲＵ３５の構造や、接続ユニット３７によるその接続を記述する。技術設備３をこのような形で表現することは、例えばテスト１と１９等のテストと、機能ユニット９、即ちＦＲＵ３５および接続ユニット３７とを相互に論理的に関連づけることを可能とする。
【００３６】
　図３は、スーパシステムモデル３３の別の構造を示す。該モデル３３は、システムファミリに属する全ての技術設備３のシステムモデル３１を含む。そしてコンフィギュレーションの際、相応のシステムモデル３１をスーパシステムモデル３３から選択する。
【００３７】
　図４は、テストプログラム４１と、パラメータ化によってテストプログラム４１から得られるテスト４３、４５、４７との間の関連性を模式的に図示する。ここではテストプログラム４１は一般的に考えられるプログラムであり、パラメータの選択により、互いに類似する技術設備３で測定を可能にする、即ち、例えば類似する構造の機能ユニット９をチェックするものである。
【００３８】
　図５は、テストブロック５１と、これに付属する複数のテスト５３、５５、５７との関連を模式的に示す。様々なテスト５３、５５、５７をテストブロック５１に纏めると、一連のテストを１回の呼び出しで実行可能となる。これは、技術設備３で考えられる多数のテストを減らしてテストブロック５１にし、即ち、特に同じ役割をもつテストを含むテスト群や、同じ機能ユニット９を対象とするテストを含むテスト群にする。
【００３９】
　図６は、スーパテストプログラムモデル６１と、そこで生成されるテストモデル６３を模式的な図面で示す。ここでスーパテストプログラムモデル６１は、種々の技術設備３を対象とするテストプログラムモデル６５を含んでいる。このモデルには、テストの処理のために重要な情報の個々のテストへの割当を記述してある。例えばテスト４３を生成すべく、どのテストプログラム４１にどのパラメータ６７を割り当てるか、どの機能ユニット９をテスト４３でチェックするか、テスト４３にどれだけの時間６９を要するか、テストをどのテストブロック５１に割り当てるかを記憶する。この情報を、スーパテストプログラムモデル６１の全テストとテストプログラムについて記憶する。
【００４０】
　更にスーパテストプログラムモデル６１は、技術設備３に関わる全情報をテストプログラムモデル６５に纏めるべく構造化してある。この結果、全技術設備に関し、進展していく開発内容をスーパテストモデル６１で一度考慮に入れるだけで済む。
【００４１】
　自動化した処理のためには、テストモデル６３をスーパテストプログラム６１から生成するとよく、この場合、テストモデル６３は、どの機能ユニット９をどのテストブロック５１でチェックするかに関する中核情報や、テスト提案１９の順序を作成するのに必要となる情報しか含んでいない。テストブロックを実施する際、各テストブロックにこれらの情報を結びつけることが、自動的な処理に決定的に重要である。個々のテストも実施可能なときは、テストモデルが個々のテストに関する中核情報を含んでいると好ましい。このことは、エラー特定を自動化するにあたり本方法の迅速化につながる。個々のテストを的確に実施、分析できるからである。
【００４２】
　図７は、テスト結果を自動的に処理する際の情報の流れを示す。処理ユニット１３は、実施したテスト１、１９の結果５、２１に関する情報を含む。更に該ユニット１３は、例えば実施したテストがどの機能ユニット９を対象とするかの情報を含むテストモデル６３にアクセスする。分析を基に次のテストを提案すべく、処理ユニット１３は、機能ユニット９の構成における技術設備３の構造に関する情報を含むシステムモデル３１にもアクセスする。
【００４３】
　そして処理ユニット１３は、故障の可能性がある機能ユニット９と、その故障確率１５に関する情報を供給する。更に処理ユニット１３は、技術設備３の故障を特定するための重要度に従って配列されたテスト提案１９のリストを供給する。故障確率１５の精密化に成功した後、処理ユニット１３は、機能ユニット９のうちどれが故障した機能ユニット１７であるかに関する情報を供給する。
【００４４】
　これに加えてこの図表は、テストモデル６３とテストプログラムモデル６５とスーパテストプログラム６３との関係およびシステムモデル３１とスーパシステムモデル３３との関係を示している。
【００４５】
　図８は、自動化した処理の手順をフローチャートで示す。処理開始７１の後、最初に情報フィルタリング７３を実行する。この際、保存中の以前のテスト結果が存在すれば、これが有用な情報であるか否かを判定した後、最新のテスト結果を伝送する。
【００４６】
　第２のステップである統合７５では、システムモデル３１とテストモデル６３に由来する情報を用いてテスト結果を分析する。例えばどの接続ユニット、例えばケーブルがテストに関与していたかや、どの交換可能な機能ユニット、例えばＦＲＵがテストに関与していたかをチェックする。引き続いて数学モデルにより、最新のテストから得られた故障確率と、以前のテストで求められた故障確率とを組み合わせる。
【００４７】
　第３のステップである診断７７では、例えば故障確率と限界故障確率を比較して、数学モデルの結果を評価する。そのために、各故障確率を大まかな分類に区分する。
【００４８】
　故障確率が限界故障確率を上回っているときは、そのテストにより、故障した機能ユニットの特定に成功したことになる。
【００４９】
　一義的な結果が得られなかった場合、第４のステップである提案７９で、次のテスト、即ち故障確率を精密化するテストを、テストモデル６３から探し出す。補足的に、システムモデル３１に由来する情報を援用する。新たなテストの決定は排除原理を用いて行うことができ、即ち故障の可能性がある機能ユニットの群を狭めていく。別案として、選択した機能ユニットのテストにより、故障確率を一層有意な証言性の高いものへ的確に変えていく方法もある。そのため、例えば複雑性や時間コストに従って配列した項目の中から提案する。これをもって自動的な処理の終了８１となる。テストを、テストブロックを用いて行うなら、テストブロックが自動的な処理の対象になる。
【００５０】
　図９は、図８に示す自動的な処理で行う統合７５の手順を詳しく説明している。統合のスタート８３の後、まず第１のステップで、どのテストを実施したかのチェック８５を行う。この際、テストはテストブロックの過程で実施してもよい。次いで、独自のサイクルでテストの機能ユニットを分析する。
【００５１】
　そのため第２のステップ８７で、テストの第１の機能ユニットを選択する。第３のステップ８９では、このユニットの分だけ数学モデルを拡張させ、第４のステップ９１では、更に当該ユニットの条件的な確率を数学モデルに取り入れる。例えば特別に障害を受けやすい機能ユニットについては高い故障確率を取り入れる。第５のステップ９３では、更に別の機能ユニットがテストに関与していたかどうかをチェックし、関与していたならば、テストすべき全ての機能ユニットを考慮しきる迄、ステップ８７から９３を繰り返す。
【００５２】
　第６のステップ９５では、例えばテストブロックの過程で、他のどのテストを実施したかをチェックする。これに属する機能ユニットについては、同じくステップ８５から９５を実行する。
【００５３】
　次いで、最も重要な第７のステップ９７で、該当する機能ユニットの故障確率を数学モデルで算出する。これをもって統合のフローチャートの終了１０１となる。
【００５４】
　本発明は、完全自動式の故障特定も可能にするものである。例えばサービス技術者や、例えば磁気共鳴断層撮影装置等の技術設備の運営者が、不十分な結果や機能のエラーに基づいて設備の不良状態を認めると、テストソフトウェアを使って、例えば次のような故障特定の手順を開始できる。
【００５５】
　テストソフトウェアが第１のテストを実施し、このテストが、例えば故障している機能ユニットを示唆していなかったとする。これに付属する第１のテスト結果を自動的に分析し、第１のテストでチェックしなかった全ての機能ユニットが潜在的に故障している仮定として分類し、以後に検査すべき機能ユニットの群を形成する。
【００５６】
　引き続き、テストソフトウェアにより第２のテストを実施し、例えばこのテストもやはり故障している機能ユニットを示唆しなかったとする。改めて自動的な処理をすることで群を更に絞り込み、第３のテストを提案する。この第３のテストで初めて、第３のテストでチェックした機能ユニットの１つが故障していることが示唆されたとする。第３のテスト結果の自動的な処理により、群を明確に絞り込める。故障している機能ユニットが一義的に特定できる迄、割り当てた故障確率を精密化する更に別のテストを実施する。このとき、例えばテスト結果の分析、故障確率の割当、次のテストの提案と実施といった自動的な処理のサイクルを、本発明の方法に基づいて行う。
【００５７】
　完全自動化した故障特定法の利点は、多数のテストを自動的に実施し、時間を要するサービス技術者との相互作業があまり必要ないので、エラー特定迄に必要な時間を短縮できることにある。
【００５８】
　自動化の程度が低いテストソフトウェアの変形例では、故障した機能ユニットを絞り込むべく、どのテスト又はテストブロックを最初に実施するかを、例えばサービス技術者自身が決める。本発明に基づくテスト結果の処理の後、提案されたテストの中から次のテストをサービス技術者が選択し、個人的な専門知識を故障特定に取り入れる。
【００５９】
　図１０は、磁気共鳴システムで用いられる通信リンクで故障したユニットを特定する手順の第１の例を示している。この図面は、プロセッサを起点として、ケーブルを経て相互につながった種々のＦＲＵを有する、ＣＡＮ（コントロールエリアネットワーク）バス１１０の構造を示している。本例では、プロセッサのＣＡＮバス出力部１１１から始まるリンクは次のＦＲＵで構成されている。即ち、ＩＯＰ（Input／Output and Power-Board（出入力パワーボード））ユニット１１３、ＲＦコントロールユニット１１５、ＲＦ増幅ユニット１１７、ＰＴＡＢ（patient table（診療台））ユニット１１９、ＬＣＣＳ（Local Coil Channel Selector（局所コイルチャンネルセレクタ））ユニット１２１、およびＢＴＢ（Body Tune Box（身体同調ボックス））ユニット１２３である。
【００６０】
　これらＦＲＵは、１つのユニットの出力部から次のユニットの入力部へ通じるケーブルを経て互いにつながっている。ケーブルが故障すると、次のＦＲＵと通信できない。他方、例えばＬＣＣＳユニット１２１のような特別なＦＲＵとの通信は不可能だが、それにも係わらず、次のユニット（この場合にはＢＴＢユニット１２３）との通信は可能な場合もある。そうした状況から、ＣＡＮバスのケーブルが不完全なのか、それともＬＣＣＳ１２１が故障していて交換すべきなのかを推定できる。
【００６１】
　システムモデルには、どの順序でＦＲＵが相互に接続されているかについての、ＣＡＮバスの記述が含まれている。テストブロックは、そのつどＦＲＵとの通信をチェックするテストを纏めることになる。テストモデルには、特別なＦＲＵと通信可能とすべく、どのケーブルやＦＲＵがどのテストの経路にあたるかが記憶される。テストモデルとシステムモデルを用いて、故障を自動式に特定できる。
【００６２】
　例えばＬＣＣＳユニット１２１との通信テストがうまくいかなかったが、ＢＴＢユニット１２３との通信テストはまだ実施されていないとする。このようなテストを本方法で提案するのは、ＰＴＡＢユニット１１９とＬＣＣＳユニット１２１の間のケーブル故障と、ＬＣＣＳユニット１２１の故障とを区別するためである。
【００６３】
　図１１は、磁気共鳴断層撮影装置のＲＦシステム１３０で故障しているユニットを特定する手順の第２の例を示す。ＲＦシステム１３０は、ケーブルで互いにネットワーク化された多数のＦＲＵからなる。ＲＦシステム１３０は、例えばループケーブル１３５を経て受信機１３３と接続された送信機１３１を含む。受信機１３１と送信機１３５は、タイムベースケーブル１３６を経て同期化の役目をするタイムベース１３７とつながっている。送信機１３１は更にＴＴＸ（Tuned Transmitter Output（同調トランスミッタ出力部））ケーブル１４１を経てＬＣＣＳユニット１３９と接続されている。ＬＣＣＳユニット１３９は更に受信機１３１と接続されている。送信機１３１は、これに加えてＲＦ増幅ユニット１４３とも接続されている。磁気共鳴断層撮影装置のその他のシステムユニット１４５も、同じくＲＦ増幅ユニット１４３やＬＣＣＳユニット１３９と接続されていてよい。
【００６４】
　この種の複雑なシステムでは、一般に、只１回のテストで故障を発見することはできない。複数のＦＲＵとケーブルをチェックする、このシステムでの非常に単純なループテストは、送信機１３１からループケーブル１３５を経て受信機１３１への測定を実施する。このテストは、追加的に、タイムベース１３７とタイムベースケーブル１３６を必要とする。このテストがエラーを報知したときは、送信機１３１、ループケーブル１３５、受信機１３１、タイムベース１３７とタイムベースケーブル１３６の故障の可能性がある。
【００６５】
　関与するＦＲＵの数を絞り込むべく、送信機１３１からＴＴＸケーブル１４１を経てＬＣＣＳユニット１３９に達し、再び受信機１３１迄戻る第２のループテストを実施することができる。この場合、ループケーブル１３５は迂回されるので、このテストでエラーが発生しなければ、ループケーブル１３５が故障していると推定できる。第２のループテストでもエラーが出たときは、送信機１３１、受信機１３１、タイムベース１３７およびタイムベースケーブル１３６が故障している可能性があり、次のテストを実施せねばならない。ＴＴＸケーブル１４１とループケーブル１３５の二重故障の可能性を排除するためにも、同じく次のテストが必要である。
【００６６】
　図１２は、ＲＦシステム１３０での２回のテストに基づく故障確率を組み合わせる際の手順を例示する。第１のテスト１５１は、チェックした部品（送信機１３１、ＴＴＸケーブル１４１、ＬＣＣＳユニット１３９および受信機１３１）の１つに存在する故障を示唆している。それに伴い、故障確率はこれら各コンポーネントについて２５％である。補足として第２のテスト１５３がエラーメッセージを出すことなく成功すれば、チェックした部品（送信機１３１、ＴＴＸケーブル１４１、ＬＣＣＳユニット１３９およびシステムユニット１４５）の何れも故障していないので、テスト１５１と１５３の結果を組み合わせて処理すると、受信機１３１が故障した機能ユニットであると特定できる。
【００６７】
　複数回のテストに基づいて故障確率を割り当てるとき、状況によっては、テスト又はテストした機能ユニットに応じて、例えば特別に障害を受けやすい機能ユニットは故障確率が高くなるような重みづけを、故障確率に施すとよい。更に、故障確率に関する命題を立てなければならない場合には、夫々の故障確率を互いに標準化し、標準化した故障確率によって数学モデルで計算し、結論を出すべく、各故障確率を大まかな分類に区分けするのが好ましい場合がある。故障確率の計算に適用できる数学モデルの一例には、ベイズのネットワークモデルがある。
【図面の簡単な説明】
【００６８】
【図１】本発明の実施例を説明するためのフローチャート。
【図２】スーパシステムモデルからのシステムモデルのコンフィギュレーションを示すフローチャート。
【図３】スーパシステムモデルの別案の構造を示す図。
【図４】テストプログラムと、これに属するテストとの間の関連性を示す図。
【図５】テストブロックと、これに属するテストとの間の関連性を示す図。
【図６】スーパテストプログラムモデルからのテストモデルのコンフィギュレーションを示す図。
【図７】テスト結果を自動的に処理する際の情報の流れを示すフローチャート。
【図８】自動化された処理のフローチャート。
【図９】図８の自動化された処理の際の統合を示すフローチャート。
【図１０】磁気共鳴断層撮影装置で用いられる通信リンクで故障したユニットを特定する第１の例を示すフローチャート。
【図１１】磁気共鳴断層撮影装置のＲＦシステムで故障したユニットを特定する第２の例を示すフローチャート。
【図１２】２つのテストに依拠する故障確率を組み合わせた場合の手順を示す図。
【符号の説明】
【００６９】
１、４３、４５、４７、５３、５５、５７、１５１、１５３　テスト、３　設備、５、２１　テスト結果、７、１１　情報、９、１７　機能ユニット、１３、３７　処理ユニット、１５　故障確率、１９、７９　テスト提案、３１　システムモデル、３３　スーパシステムモデル、３５　ＦＲＵ、４１　テストプログラム、５１　テストブロック、６１　スーパテストプログラムモデル、６３　テストモデル、６５　テストプログラムモデル、６７　パラメータ、　６９　時間、７１、８３　スタート、７３　情報フィルタリング、７５　統合、７７　診断、８１、１０１　終了、８５　チェック、８７　機能ユニットの選択、８９　モデルの拡張、９１、９３、９５、９７　ステップ、１１０　ＣＡＮバス、１１１　ＣＡＮバス出力部、１１３　ＩＯＰユニット、１１５　ＲＦコントロールユニット、１１７、１４３　ＲＦ増幅ユニット、１１９　ＰＴＡＢユニット、１２１、１３９　ＬＣＣＳユニット、１２３　ＢＴＢユニット、１３０　ＲＦシステム、１３１　送信機、１３３　受信機、１３５、１３６、１４１　ケーブル、１３７　タイムベース、１４５　システムユニット
【図１】
2004118839.tif 000003
【図２】
2004118839.tif 000004
【図３】
2004118839.tif 000005
【図４】
2004118839.tif 000006
【図５】
2004118839.tif 000007
【図６】
2004118839.tif 000008
【図７】
2004118839.tif 000009
【図８】
2004118839.tif 000010
【図９】
2004118839.tif 000011
【図１０】
2004118839.tif 000012
【図１１】
2004118839.tif 000013
【図１２】
2004118839.tif 000014