JP4984580B2

JP4984580B2 - 不具合対策支援装置

Info

Publication number: JP4984580B2
Application number: JP2006066043A
Authority: JP
Inventors: 喜宏王; 憲一黒谷; 秀之伊藤; 光俊飯野; 博成水谷; 光宏中村
Original assignee: Fuji Electric Co Ltd
Current assignee: Fuji Electric Co Ltd
Priority date: 2006-03-10
Filing date: 2006-03-10
Publication date: 2012-07-25
Anticipated expiration: 2026-03-10
Also published as: JP2007241861A

Description

本発明は、１以上の実体（部品、またはユニットなど）から生産される製品に関わる生産システムに生じる不具合に対する対策を支援する不具合対策支援装置に関し、特に、不具合の対策支援を効率よく行うことが可能な不具合対策支援装置に関する。

従来、１以上の部品から生産される製品に関わる生産システムにおいては、その製造工程中、試験段階、などの各段階において、設計の不備、人為的なミスなどによって、各種の不具合が生じている。そして、このような不具合を未然に防ぐために、様々な方法が考えられている。

その内のあるものは、生産システムを不具合を検出する主たる対象としてとらえており、また、別のものは、その不具合を検出する対象を、生産システムに限らず、より広範囲のシステムに対して設定している。

以下の説明においては、様々な技術を背景技術として説明するが、それらは、上記した区分に従って、生産システムを主たる対象に据えるものと、生産システムに限らず、より広い範囲のシステムをその守備範囲に据えるものとに大別される。

生産システムにおける、不具合を検出する手法には、当然、様々な手法があるが、それらの手法において用いられる基本的な概念として、部品表（Bill Of Material、以下ではＢＯＭと呼ぶ）という概念がある。この部品表は、基本的には、１つの製品を構成する部品のリストを一覧表として提示したものであり、種別としては、設計に用いられるエンジニアリング−ＢＯＭ（以下では、Ｅ−ＢＯＭと呼ぶ）と、製造に用いられるマニュファクチュアリング−ＢＯＭ（以下では、Ｍ−ＢＯＭと呼ぶ）とがある。Ｅ−ＢＯＭは、製品がどのような部品（部位）によって構成されているのかを示しており、また、Ｍ−ＢＯＭは、Ｅ−ＢＯＭの情報を製品計画や、スケジュールなど、実際の生産活動の中で利用可能にするための情報を保持している。

また、生産システムにおける、不具合を検出する手法において用いられる、この他の概念としては、注目対象の耐性を示すストレングスと、その対象とインターフェイスを有する別の対象からその対象に加えられ、場合によっては、その対象に不具合を起こさせる駆動力を示すストレスとによって、不具合の発生メカニズムを解析するストレス・ストレングス・モデル（Stress Strength Model、以下ではＳＳＭと呼ぶ）がある（下記非特許文献１参照）。なお、ＳＳＭは、元々は製造業における不具合の未然防止を目的とするものである。

そして、上記した各概念を用いた、生産システムにおける不具合を検出（分析）する方法として、下記非特許文献２に示される、段階的信頼性設計支援システム（以下では、古賀−青山モデルと呼ぶ）が知られている。

この古賀−青山モデルは、段階的設計（トップダウン設計）における信頼性評価を対象分野としており、製品を「実体」、「属性」、「インターフェイス」の３要素により表現している。そして、製品がどのような部品によって構成されるのかを示す情報（すなわち、上記Ｅ−ＢＯＭ）を用いて、その製品に生じる不具合の分析を行っている。その際、上記ＳＳＭ方式に基づいて、故障（不具合）の発生メカニズムが明らかにされる。しかし、古賀−青山モデルでは、そのメカニズムの解析結果を参照しつつ、別プロセスとして、Fault Tree Analysis（以下では、ＦＴＡと呼ぶ）や、Failure Mode and Effects Analysis（以下では、ＦＭＥＡと呼ぶ）等の信頼性評価を行っており、作業として二度手間になっている。

すなわち、古賀−青山モデルでは、ＳＳＭ方式のような狭義の定量的アプローチのための手法はうまく取り込めても、ＦＴＡやＦＭＥＡ方式のような概念的にはより広範囲の対象に適用される、必ずしも定量的なアプローチを前提としていない手法を取り込むことは困難である。このことが、上記したＳＳＭでの解析を行った後に、別プロセスで、ＦＴＡやＦＭＥＡ方式による解析を行うという二度手間が古賀−青山モデルにおいて回避できない原因と考えられる。つまり、古賀−青山モデルと、ＦＴＡやＦＭＥＡ方式との間にどのような連携（リンク）を設ければいいのか必ずしも明らかではない。

また、上記ＦＭＥＡ方式の場合には、Ｅ−ＢＯＭとは独立に、特定の不具合事象に着目して、その危険優先度をランク付けしており、複数の部品から生産される製品に生じる不具合の分析に直接適用できるような方式とはなっていないという事情もある。

なお、ここで、ＦＴＡは、（生産システムに限らずより広範囲の）システムにおける不具合事象の原因分析（人的原因、ソフトウェアによる要因も含む）を対象分野としており、不具合原因となる事象を、論理ゲートを介してツリー構造（故障木）の各部に配置することで、関連部の脆弱性の指摘と、対応策の勧告を行うことができるものである（下記非特許文献３参照）。

また、ＦＭＥＡは、（生産システムに限らずより広範囲の）システムにおける不具合未然防止設計、不具合事象の影響分析・対策案勧告（ハードウェアの単一故障、工程設計が主対象）を対象とし、システムの構成要素の機能的な接続関係を明確にし、下位レベルの不具合事象が上位レベルにボトムアップ的にどのように影響するかを故障等級、対策案を加味したワークシート（表）を作成しながら系統的に検討し、設計図面に織り込まれた信頼性を評価するものである。この技法では、不具合事象の危険優先度を発生頻度・影響度・検出難易度に基づいてランク付けすることにより、設計の脆弱性に対して順位付けを行うことができ、設計の見直しと対策案を勧告できる。また、不具合事象の全てについて不具合を未然に防止するための検討を行うことができる（下記非特許文献３参照）。

このように、ＦＴＡやＦＭＥＡなどの各種方式は、生産システムに限らず、より広範囲のシステムを対象としている。このため、生産システムという若干、具体的なシステムに適用しようとした場合、ＦＴＡやＦＭＥＡなどが有する抽象的な概念を、その具体的なシステムに落とす作業が必要となり、それが、上記した古賀−青山モデルが、ＦＴＡやＦＭＥＡなどの各種方式とリンクして、１つのシステムを構成していない原因とも考えられる。

なお、上記ＦＭＥＡ方式は、製造工程情報を加味した分析を行う際に用いられる代表的な方式（ロジック）の１つである。上記のことから明らかなように、古賀−青山モデルは、一体的なシステムとしては、製造工程情報を加味できておらず、したがって、例えば、製品を構成する個々の部品の中のある部品の製造工程に原因があって、故障（不具合）を引き起こすような場合には対応できていない。
田村泰彦、他２名「不具合に関する構造化知識の活用システムの開発」古賀毅、他２名「信頼性設計を段階的に支援する故障情報マネージメントシステムの提案と構築」２００１年、日本機械学会第１０回交通・物流部門大会鈴木順二郎他著「ＦＭＥＡ−ＦＴＡ実施法」１９８２年、日科技連

本発明の課題は、不具合の対策支援を効率よく行うことが可能な不具合対策支援装置を提供することである。

本発明の一態様では、１以上の実体から生産される製品に関わる生産システムに生じる不具合に対する対策を支援する装置を扱う。この装置を用いて不具合に対する対策を支援するに際しては、上記実体で発生しうる不具合現象の網羅的な集合を対策支援に先立って抽出することが必要であるように、通常、思われている。

しかしながら、不具合に対する対策を支援するに際し、上記実体で発生しうる不具合現象の網羅的な集合を対策支援に先立って抽出しても、必ずしも有効な対策支援にはならない。つまり、不具合現象は、量産部門の現場担当者などからくる生データであり、表現上からも、例えば同一現象に対して、様々な表現が可能であるから、かえって混乱をまねいてしまう。

本発明の特徴は、１以上の実体から生産される製品に関わる生産システムに生じる不具合に対する対策を支援する装置において、前記実体で発生しうる不具合現象の網羅的な集合を示す情報を記憶する第１の不具合網羅記憶手段と、前記第１の不具合網羅記憶手段に記憶されている不具合現象を形態別に整理して得られる不具合モードの網羅的な集合を示す情報を記憶する第２の不具合網羅記憶手段と、前記実体で発生しうる不具合現象を形態別に整理して得られる不具合モードの網羅的な集合を示す情報を記憶する不具合網羅記憶手段と、予め製品構造情報と製造工程情報とを互いに関連付けて表現したモデル情報を製品・工程モデルとして記憶する製品・工程モデル記憶手段と、仕様書や標準書のデータ、製造方法に関する知識や生産システムにおける知見・ノウハウに関する知識等からなる知識データを記憶する知識データ記憶手段と、をあらかじめ備え、
前記第１及び第２の不具合網羅記憶手段に記憶されている前記網羅的な集合を示す不具合現象、不具合モード、及び、前記知識データ記憶手段に記憶されている知見・ノウハウ等の各種データをユーザが読み出して且つ該データを参照し、更に前記製品・工程モデル記憶手段に記憶された前記モデル情報を読み出して該モデル情報を骨組みとして持ち、該骨組みに対してユーザが該モデル情報に展開されている各属性に対して対応する属性値を記述するとともに既存の各種方式を用いて判定を行うロジック、並びに前記製品・工程モデル記憶手段に記憶された前記製造工程情報の属性としての状態情報、状態遷移の方向に係る情報を付加して品質知識データベースを構築する手段と、
所定の不具合現象が発生した際に、構築された前記品質知識データベースを読み出して、前記モデル情報中に存在する実体に複数の属性データを関連付ける手段および前記関連付けられた属性データの少なくとも一部を用いて前記実体における不具合現象の発生確率を算出して不具合の原因追求・影響分析による対策支援を行う第１の不具合対策支援手段と、
所定の不具合が起こる前に、構築された前記品質知識データベースを読み出して、前記モデル情報中に存在する実体に複数の属性データを関連付ける手段および前記関連付けられた属性データの少なくとも一部を用いて前記実体を用いる製品に内在する危険因子を危険優先度として算出し、該危険優先度を不具合未然防止支援に用いる第２の不具合対策支援手段と、
前記第１の不具合対策支援手段の前記不具合の原因追求による対策支援に対しては要因候補リストを、また前記不具合の影響分析による対策支援に対しては影響範囲と影響度候補リストを、それぞれ確率（寄与率）順にソートして出力し、一方、前記第２の不具合対策支援手段の前記不具合の未然防止支援による対策支援に対しては対策候補リストを確率（寄与率）順にソートして出力する出力手段と、を備えることである。

本発明の不具合対策支援装置は、１以上の実体から生産される製品に関わる生産システムに生じる不具合に対する対策を支援する装置である。そして、実体で発生しうる不具合現象を形態別に整理して得られる不具合モードの網羅的な集合を用いて対策検討を行っている。そして、この不具合モードを対策支援に用いられる各種方式の要素と関連付けることで、その各種方式を利用して対策支援を行うものである。上記各種方式には、ＦＴＡやＦＭＥＡなどのように、生産システムに限らず、より広範囲のシステムを対象とする方式も含まれる。不具合モードの網羅的な集合は、ＦＴＡやＦＭＥＡなどが有する抽象的な概念を、生産システムという若干、具体的なシステムに適用しようとした場合に、その具体的なシステムに落とす作業を容易にする。よって、対策支援を行う際に、ＦＴＡやＦＭＥＡなどを含む各種方式との連携が可能となり、不具合の対策支援を効率よく行うことができる。

以下、本発明の実施の形態を、図面を参照しながら詳細に説明する。
本発明は、１以上の部品から生産される製品に関わる生産システムを基本的には対象とし、その生産システムにおいて生じる不具合に対する対策を支援するものである。対策支援のより具体的な内容としては、不具合の分析を行うことや、また、その不具合を未然に防止する際の支援を行うことなどがある。

図１は、上記した生産システムにおける、製品が市場に投入されるまでのフェーズの流れを説明する図である。図に示すように、製品は、「製品設計」、「生産準備」、「量産製造」の各フェーズを経ることによって市場に投入される。

始めのフェーズである製品設計フェーズでは、例えば市場情報や商品企画情報に基づいて、機能、部品構成、形状、材質、信頼性等の設計が行われる。そして、この製品設計の結果として、製品図面、材質、などの製品モデルデータをデータベースに出力する。この製品モデルデータ中には、Ｅ−ＢＯＭや、設計ＦＭＥＡが含まれていてもよい。

次のフェーズである生産準備フェーズでは、上記製品モデルデータ（Ｅ−ＢＯＭ、設計ＦＭＥＡ、など）の他に、設備能力（Ｃ／Ｔ）、工程能力（Ｃ／Ｔ）、作業性（点検、工具交換）、治工具能力、設備・治工具コスト、などの各種制約条件を読み込み、工程／設備／治工具の設計を行う。すなわち、製造工程構成のフローを設計し、Ｍ−ＢＯＭを作成すると共に、設備・治工具選択、レイアウト設計や、工作図（加工部位・基準・寸法・方法、ツールパス）の作成や、製造工程信頼性の設計（工程ＦＭＥＡと呼ぶ）を行う。この生産準備の結果として、設備／治工具仕様書、設備／治工具配置図、工作図、レイアウト図、プログラム、パラメータ、製造条件、工程フロー、作業要領、品質基準、Ｍ−ＢＯＭ、工程ＦＭＥＡなどの各データをデータベースに出力する。

そして、出力されたそれらの各データに基づいて、後段のフェーズである量産製造フェーズでは、部品、ユニットの加工組み付け、製品の組み立て、設備保全、品質保証、などを行う。

そして、これら各フェーズを経て、完成品としての製品が市場に投入される。
この製品に生じる不具合情報には、製品を市場に投入後に生じる市場からの不具合情報（以下、市場不具合と呼ぶ）と、工場での製造時や、上記各フェーズ内で生じる不具合情報（以下、生産不具合と呼ぶ）とがある。

図２は、図１の生産システムで不具合が発生した場合に行う、不具合処理の業務フローを示す図である。
図２に示すように、市場不具合が発生した場合や、生産不具合（図では、量産設備フェーズ中での組立工場において、生産不具合が発生している）が発生した場合には、不具合連絡票が、現場担当者等のクレーム発行部門によって作成される。

ステップＳ１では、この不具合連絡票に基づいて、不具合現象の確認が行われる。不具合現象の確認では、一次原因の特定、重要性の決定（すぐに対応するのか、後回しにしてもよいのかの決定）、優先順位の決定、発生頻度の確認、送り先の決定、が行われる。次のステップＳ２の処理では、Ｓ１で確認された現象について処置が実施され、ステップＳ３では、不具合の真因を分析すべく、不具合の原因追求が行われる。

次のステップＳ４では、ある部位に発生した不具合が影響する部品と工程の範囲が調査され、影響程度の把握と、送り先の決定が行われる。
なお、上記したステップＳ１〜Ｓ４の処理は、実際に発生した不具合に対応して行われる処理である。これに対し、後続のステップＳ５〜Ｓ７は、後述する危険優先度の観点から、発生した場合に、生産設備等に極めて大きな損害を与える可能性がある不具合について、未然に防止すべく対策を予め講じておくために行われる処理である。

まず、ステップＳ５で対策検討が行われる。ここでは、代替案の検討（一次対策、恒久対策）、対策による効果の見積もり、対策の実行順序の決定、などが行われる。そして、次のステップＳ６では、前ステップＳ５で検討された代替案の中から実行する案を選択し、実施決定し、実行部署に通知する。この実施部署への通知は、例えば製品設計部署に対しては仕様見直しであり、また、工程設計部署に対しては、標準書・基準書、作業手順書、加工法の見直しであり、また、設備設計部署に対しては、設備・工具仕様、作業環境、レイアウトの見直しであり、また、量産製造部署に対しては、ポカヨケ対策の見直しである。

上記通知を受けて、例えば製品設計部署では仕様書図面が、工程設計部署では基準書が、設備設計部署では仕様書図面が、それぞれ修正される。また、量産製造部署では、例えば作業手順書中のポカヨケ対策の内容に関連する部分が修正される。

続くステップＳ７では、前ステップＳ６で通知を行った各部署（各実行部門）からの実施をした旨の通知、または、その実施結果のフィードバックを受ける。そして、ステップＳ８で、処理結果、または、再発防止対策を上記クレーム発行部門に報告して、一連の不具合処理の業務フローを終了する。

図３は、本発明の一実施形態の生産システムにおける不具合対策支援システムの構成を示すブロック図である。
図において、不具合対策支援システム１は、登録部１０、知見・ノウハウ蓄積部２０、参照部３０、及び不具合対策支援部４０から構成されている。

知見・ノウハウ蓄積部２０は、不具合に関する各種網羅表を記憶する不具合網羅表記憶部２１、製品構造情報と製造工程情報とを互いに関連付けて（すなわち、統合的に）表現したモデル情報を格納するプロダクト・プロセス・モデル・データベース（Product Process Model Data Base、以下、ＰＰＭＤＢと呼ぶ）２２、設計仕様書データ、標準書データ、基準書データ、製造方法に関する知識や生産システムにおける知見・ノウハウに関する知識等からなる知識データを記憶する知識データ記憶部２３、及び、上記した不具合網羅表記憶部２１、知識データ記憶部２３、に記憶されている各種データを参照しつつ、ＰＰＭＤＢ２２のモデル情報を骨組みとして作成された、後述の不具合の対策支援を行う際に利用されるデータベースである、品質知識データベース（Quality Analysis / Question Answering Knowledge Data Base、以下、ＱＡ２−ＫＤＢと呼ぶ）２４、を備えている。なお、不具合網羅表記憶部２１、ＰＰＭＤＢ２２、ＱＡ２−ＫＤＢ２４については後述する。

この不具合対策支援システム１においては、例えば登録部１０、参照部３０、及び不具合対策支援部４０は、クライアント装置が有する機能を提供しており、また、知見・ノウハウ蓄積部２０は、サーバ装置が有する機能を提供している。

本システムのユーザは、登録部１０を介して、事前に検討した設計情報を基にして、網羅表データ記憶部２１、ＰＰＭＤＢ２２に、それぞれ保持されているデータの登録／削除などのメンテナンスを行う。

また、本システムのユーザは、参照部３０を介して、知見・ノウハウ蓄積部２０にアクセスして、知識データ記憶部２３やＱＡ２−ＫＤＢ２４に情報として保持されている知見・ノウハウを参照することができる。

また、本システムのユーザは、不具合対策支援部４０を介して、知見・ノウハウ蓄積部２０にアクセスすることにより、製品に生じた不具合、または、生じうる不具合に対する対策支援を行う。より具体的には、製品に生じた不具合については、その原因追求と影響分析を、また、製品に生じうる不具合については、未然防止のための支援を行う。

図４は、図３のＰＰＭＤＢの概念的な構造を示す図である。
図４に示すように、ＰＰＭＤＢは、製品がどのような実体（ユニット、または、部品）から構成されるのかを示す製品製造情報、すなわち、製品が各ユニットからどのように構成されるのか、ユニットが各部品からどのように構成されるのかを示す情報を保持すると共に、製品が各ユニットからどのように製造されるのか、ユニットが各部品からどのように製造されるのか、各部品がそれぞれどのような工程によって製造されるのかを示す製造工程情報も保持している。つまり、ＰＰＭＤＢには、製品構造情報と製造工程情報とを互いに関連付けて（すなわち、統合的に）表現したモデル情報が格納されている。

より具体的には、図４においては、表現モデル５０は、以下の情報を表現している。すなわち、実体５１（ユニット１）が、実体５２（部品１−１）と実体５３（部品１−２）とから構成されるという製品構造情報と、実体５２（部品１−１）に実体５３（部品１−２）を組み合わせることによって実体５１が完成するという製造工程情報と、原材料から中間品１〜３を経て実体５２（部品１−１）が完成するという製造工程情報と、原材料から中間品１〜２を経て実体５３（部品１−２）が完成するという製造工程情報と、を表現している。

さらに詳しく述べれば、実体５２（部品１−１）から実体５１（ユニット１）に向かう矢印７１と、実体５３（部品１−２）から実体５１（ユニット１）に向かう矢印７２とによって、実体５１（ユニット１）が、実体５２（部品１−１）と実体５３（部品１−２）とから構成されるという上記製品構造情報が表現されている。
また、実体５１（ユニット１）については、状態６１（初期（準備））に向かう矢印６６と、状態６１（初期（準備））から状態６２（中間品１）に向かう矢印６７と、状態６２（中間品１）から状態６３（中間品２）に向かう矢印６８と、状態６３（中間品２）から状態６４（完成品）に向かう矢印６９とによって、実体５２（部品１−１）、及び実体５３（部品１−２）を入荷して状態６１（初期（準備））が得られ、その後、例えば実体５２（部品１−１）を組立てが行われる所定位置に移動するなどして、状態６２（中間品１）が得られ、その状態６２（中間品１）に対して、実体５２（部品１−２）を組み合わせることで、状態６３（中間品２）が得られ、その状態６３（中間品２）に対して、例えば、正しく動作するか等の検査を行って実体５１（ユニット１）が得られるという、上記製造工程情報が示されている。

また、実体５２（部品１−１）については、状態８１（原材料）に向かう矢印８６と、状態８１（原材料）から状態８２（中間品１）に向かう矢印８７と、状態８２（中間品１）から状態８３（中間品２）に向かう矢印８８と、状態８３（中間品２）から状態８４（中間品３）に向かう矢印８９と、状態８４（中間品３）から状態８５（完成品）に向かう矢印９０とによって、原材料を入荷して状態８１（原材料）が得られ、その後、その状態８１（原材料）に対して切削処理を施して、状態８２（中間品１）が得られ、その状態８２（中間品１）に対して研磨処理を施して、状態８３（中間品２）が得られ、その状態８３（中間品２）に対して表面処理を施して、状態８４（中間品３）が得られ、その状態８４（中間品３）に対して、必要な検査を行って実体５２（完成品、すなわち、部品１−１）が得られるという、上記製造工程情報が示されている。

また、実体５３（部品１−２）については、状態９１（原材料）に向かう矢印９６と、状態９１（原材料）から状態９２（中間品１）に向かう矢印９７と、状態９２（中間品１）から状態９３（中間品２）に向かう矢印９８と、状態９３（中間品２）から状態９４（完成品）に向かう矢印９９とによって、原材料を入荷して状態９１（原材料）が得られ、その後、その状態９１（原材料）に対して鍛造処理を施して、状態９２（中間品１）が得られ、その状態９２（中間品１）に対して熱処理を施して、状態９３（中間品２）が得られ、その状態９３（中間品２）に対して、必要な検査を行って実体５３（完成品、すなわち、部品１−２）が得られるという、上記製造工程情報が示されている。

図５は、図４の表現モデル５０に対応するテーブル１００を示す図である。
図５において、テーブル１００は、実体コード１０１、状態コード１０２、前状態コード１０３、状態遷移順１０４、状態遷移コード１０５、入力品目コード１０６、出力品目コード１０７、及び構成フラグ１０８の各項目によって構成される。なお、上記各項目の定義は以下の通りである。

実体コード・・・ユニットや部品などの実体に一意的に割り当てるコード
状態コード・・・各種状態に一意的に割り当てられるコード
前状態コード・・・状態コードが示す状態に遷移する前の状態に一意的に割り当てられるコード
状態遷移順・・・ユニットや部品などの１つの実体内で、その実体が完成するまでの製造工程における状態の遷移順を示すシリアル番号（通常、１から順に割り当てられる）。

状態遷移コード・・・状態遷移の条件（作業の種類）を示すコード
入力品目コード・・・ユニットや部品などの各実体の各製造工程において使用（入力）される品目に一意的に割り当てられるコード
出力品目コード・・・ユニットや部品などの各実体の各製造工程において製造（出力）される品目に一意的に割り当てられるコード
構成フラグ・・・ユニットなどの実体を構成する部品を示すフラグ
テーブル１００を参照すると、各実体（ユニット、部品）は、完成した状態（完成品）の他に、製造工程における中間的な状態もデータとして保持していることが分かる。

部品１−１（実体５２）については、実体コード１０１が「部品１−１」であるものに対応して、原材料（状態８１）、中間品１（状態８２）、中間品２（状態８３）、中間品３（状態８４）、及び完成品（状態８５）の状態コード１０２が存在している。前状態コード１０３は、それぞれの状態コード１０２に対応するものであり、その状態コード１０２に遷移する前は、どの状態コード１０２であったのかという情報を示している。これら状態コード１０２とその状態コード１０２に対応する前状態コード１０３との組み合わせによって、状態遷移によって、状態がどのように変化したかが分かる。

また、実体コード１０１が「部品１−１」であるものについて、状態遷移順１０４を参照すると、部品１−１が完成するまでの状態遷移の順番を知ることができる。
さらに、状態遷移コード１０５を参照すると、状態コード１０１で示される状態に遷移するための条件（すなわち、状態コード１０１で示される状態に遷移するために行う作業の種類）を知ることができる。なお、このような状態遷移の条件（作業の種別）には、「組立（形態維持、従属変更）」、「加工」、「塗装」、「熱処理」などがある。加工、塗装、及び熱処理では、形態は変更されるが従属は維持される（形態変更、従属維持）。

入力品目コード１０６は、上記状態遷移コード１０５に示す作業内容をどの対象（状態）に対して行うかを示すものである。よって、状態遷移コード１０５が「原材料入荷」である状態に対しては設定されていない。同様に、出力品目コード１０７は、上記状態遷移コード１０５に示す作業内容を対応する入力品目コード１０６の対象（状態）に対して実施した場合の遷移先の状態を示しており、基本的には、状態遷移コード１０５に対応する実体コード１０１と状態コード１０２との組み合わせに一致する。

なお、以上の説明は、部品１−１（実体５２）について行ったが、部品１−２（実体５３）についても同様なので説明を省略する。
また、ユニット１（実体５１）についても、部品１−１（実体５２）と同様に、図４の表現モデル５０に対応するテーブル１００に必要な項目が設定される。ユニット１の場合はさらに、構成フラグ１０８に、部品１−１と部品１−２とを示すフラグが設定される。同一の実体コード１０１に対して、このフラグが２箇所以上に設定されている場合、その実体コード１０１の実体が、このフラグによって示される２以上の実体によって構成されることが示されている。例えば図５においては、「ユニット１が部品１−１と部品１−２とにより構成される」ことが示されている。これは、図４におけるユニット１の製品構造情報に対応する内容となっている。

なお、１以上の部品から生産される製品に関わる生産システムにおいては、様々な原因によって、不具合が引き起こされるものと考えられる。その不具合を引き起こしうる潜在的な危険源のことを以下ではハザードと呼ぶことにする。なお、このハザードはあくまで概念的なものであり、説明の便宜上、用いるものである。

図６は、図４の表現モデル５０に対して、ハザードとインターフェイス情報を設定した一例を示す図である。
図６において、部品１−１は、原材料入荷時には、例えば間違った種類の原材料を入荷するなどのハザード１を有し、また、原材料を切削して中間品１へと加工する場合には、所定の手順から外れたり、その所定の手順を行うことになっている機器類が正しく動作しなかったりするなどのハザード２を有する。

また、部品１−１は、自身がインターフェイスを有する他の部品との間に相互作用がある。そして、このインターフェイスを介して、部品１−１は他の部品から、物質、信号、またはエネルギーの流れなどの相互作用を受ける。この場合には、部品１−１は、この相互作用が部品１−１の許容範囲を越えるというハザード１０を有する。その他のハザードについても同様であるので説明は省略する。

なお、以上の説明では、ユニットは２個の部品から構成されていたが、より複雑な構成とすることができることはいうまでもない。
図７は、４個の部品から構成されるユニットの表現モデルを示す図である。

図７において、ユニット３は、部品３−１、部品３−２、部品３−３、部品３−４の４個の部品から構成されている。このユニット３の表現モデルには、構成の複雑さに対応して、（当然）より多くのハザードが存在している。

本実施形態においては、このような表現モデル（または、ＰＰＭＤＢ）に対して、そのモデルが有する各実体にその実体に属する属性データ（一般には、複数の属性データ）を持たせると共に、それら属性データ内の少なくとも一部を用いて必要な情報（例えば、ある不具合の発生確率など）を算出させる構成である。

しかしながら、上記したように、不具合に対する対策を支援するに際し、上記実体で発生しうる不具合現象の網羅的な集合を対策支援に先立って抽出しても、必ずしも有効な対策支援にはならない。つまり、不具合現象は、量産部門の現場担当者などからくる生データであり、表現上からも、例えば同一現象に対して、様々な表現が可能であるから、かえって混乱をまねいてしまう。

このような事情から、本実施形態においては、不具合現象を解析対象として、ある程度定量的に扱うことを可能にするために、その不具合現象を階層的に形態別に整理した不具合モードを設けている。そして、不具合対策に用いられる各種方式（ロジック）において、この不具合モードを用いることによって、従来の狭義の定量的アプローチでは困難とされている製造工程における不具合の対策支援を、定量的に扱うことを可能としている。

例えば、従来の古賀−青山モデルでは、不具合現象の発生確率を定量的に解析するに際して、ＳＳＭ方式を用いて、ストレス＞ストレングス、の条件を満たす場合に不具合が発生するものとしている。しかし、このような定量的なアプローチはあくまで、上記した実体間におけるインターフェイスを介して伝播する相互作用にのみ適用できるものであって、その解析作業の後段には、そのＳＳＭ方式などによる解析結果を踏まえた上で、別プロセスとして、ＦＴＡやＦＭＥＡなどの各種方式を用いて因果関係や危険優先度などの分析を行っている。従来例で作業が二度手間になってしまう理由は、このＳＳＭ方式のような狭義の定量的アプローチと、ＦＴＡやＦＭＥＡ方式のような、概念的には必ずしも定量的なアプローチを前提としていないものの間にリンクがとれていないことが原因として考えられる。

本実施形態においては、ＳＳＭ方式のような狭義の定量的アプローチのための手法と、ＦＴＡやＦＭＥＡ方式のような概念的にはより広範囲の対象に適用される、必ずしも定量的なアプローチを前提としていない手法との間にリンクをとるためのデータ構造として、図３に示す各種の不具合を網羅的に記憶した不具合網羅表記憶部を有している。

図８は、その図３の不具合網羅表記憶部２１に記憶される各種網羅表を示す図である。
図８に示すように、図３の不具合網羅表記憶部２１に記憶される網羅表は、不具合（故障）部位網羅表２１ａ、不具合（故障）モード網羅表２１ｂ、不具合（故障）現象網羅表２１ｃ、不具合（故障）結果網羅表２１ｄ、不具合（故障）原因網羅表２１ｅ、不具合（故障）対策網羅表２１ｆによって構成される。なお、不具合網羅表を構成するこれら表のうち、不具合（故障）結果網羅表２１ｄ、不具合（故障）原因網羅表２１ｅ、不具合（故障）対策網羅表２１ｆは、下記非特許文献４に記載される、周知の技術である「失敗まんだら」に基づいて定義される。この「失敗まんだら」では、すべての失敗事例はヒューマンエラーであるという認識に立ち、失敗の脈絡を、人的原因→人の行動→結果という流れとして構造化する。そして、「原因」、「行動」、「結果」のそれぞれのフェーズをまんだらとして、さらに、それらのまんだらを階層分類し、体系化・標準化を行い、これにより失敗を知識化する。
統括畑村洋太郎「失敗知識データベースの構造と表現」平成１４年１２月、科学技術振興財団失敗知識データベース整備事業以下に、図３の不具合網羅表記憶部２１に格納される各網羅表のデータ例を図９〜図１８を参照しつつ説明する。なお、本実施形態では、「不具合」は「故障」より概念的に広いものと解釈している。すなわち、「不具合」は実体、状態、更には物事について、その事象に関する望ましくないことをいうのに対して、「故障」は製品（もの）について、その製品（もの）に関する望ましくないことをいう。

図９は、ある製品系統に対応する不具合（故障）部位網羅表２１ａの一例を示す図である。不具合（故障）部位網羅表２１ａは、不具合（故障）が発生する部位を網羅的に定義している。なお、図に示されるように、部位は階層的に定義されている。

図１０、及び図１１は、ある製品系統の製造工程や製品系統に対応する不具合（故障）モード網羅表２１ｂの一例を示す図である。不具合（故障）モード網羅表２１ｂは、その製品系統に発生しうる不具合（故障）モードを網羅的に定義している。ここで、不具合（故障）モードとは、不具合（故障）現象を形態別に整理して得られるパターンであり、その不具合（故障）モードを階層的に整理して、不具合（故障）モード網羅表が得られる。不具合（故障）モードの例としては、断線、短絡、折損、磨耗、などが挙げられる。なお、図１０は、ヒューマンエラーをベースとした不具合（故障）モードの例を示しているのに対して、図１１は、物理現象をベースとした不具合（故障）モードの例を示している。

図１２、及び図１３は、ある製品系統の製造工程や製品系統に対応する不具合（故障）現象網羅表２１ｃの一例を示す図である。不具合（故障）現象網羅表２１ｃは、その製品系統に発生しうる不具合（故障）現象を網羅的に定義している。ここで、不具合（故障）現象網羅表２１ｃでは、人間が器官などで感知できることや、計器などで計測できることを対象（表の要素）としている。つまり、不具合（故障）現象とは、不具合（故障）と認識された現象そのものを意味する。例えば、切れる、動かない、接触する、折れる、すり減る、変な音がする、電圧がｘｘＶを越える、変な匂いがする、熱い、表面がざらついている、等である。なお、図１２は、ヒューマンエラーをベースとした不具合（故障）現象の例を示しているのに対して、図１３は、物理現象をベースとした不具合（故障）現象の例を示している。

なお、図１２、及び図１３の不具合（故障）現象網羅表２１ｃでは、不具合（故障）現象を上記した不具合（故障）モードと対応付けて示している。このような表示形式とすることにより、不具合（故障）現象に対応する不具合（故障）モードを以後行う解析に用いるようにすれば、同一現象に対しても、不具合連絡票を作成する（現場）担当者によって、様々な表現が可能であり混乱をまねくという、不具合（故障）現象を解析に用いた場合の不都合を回避でき、担当者（本システムのユーザ）の習熟度、熟練度などの属人的な因子を減らすことができる。

なお、図１２に示すように、特にヒューマンエラーについては、不具合（故障）現象という表現の代わりにエラー現象という表現を用い、対応する不具合（故障）モードの方もエラーモードと呼ぶようにして、他の不具合（故障）現象、不具合（故障）モードから区別するようにしてもよい。

図１４は、ある製品系統に対応する不具合（故障）結果網羅表２１ｄの一例を示す図である。ここで、不具合（故障）結果とは、その製品系統の製品やその製造工程に不具合（故障）が発生したことに伴い、その不具合（故障）の発生の結果として表れる損害を示している。そして、不具合（故障）結果網羅表２１ｄは、そのような不具合（故障）の発生の結果として表れる損害を階層的に分類して網羅的に定義している。図１４においては、この階層的分類の上位項目については、上記した「失敗まんだら」に合わせて項目を設定している。この「失敗まんだら」では、結果は、人的、物的、組織・社会的な結果、外部への影響を伴う結果、これから必ず起こる結果、起こるかも知れない結果、に分類されており、図１４でも、ほぼこの分類に沿って分類されている。ただし、当然のことではあるが、階層がより下位の項目については、この「失敗まんだら」を適用しようとする個々のシステムに応じて異なってくる。本実施形態の実体から生産される製品に関わる生産システムにおいては、上位項目が「物への結果」に属する下位項目は、「破損」、「不良現象」、「機能不全」となっており、さらに、項目「不良現象」に属する下位項目は、「電気故障」、「化学現象」、「熱流体現象」、「機械現象」などとなっている。

図１５、及び図１６は、ある製品系統の製造工程や製品系統に対応する不具合（故障）原因網羅表２１ｅの一例を示す図である。ここで、不具合（故障）原因とは、その製品系統の製造工程やその製品に発生する不具合（故障）の原因を指している。そして、不具合（故障）原因網羅表２１ｅは、そのような不具合（故障）原因を階層的に分類して網羅的に定義している。

なお、図１５は、ヒューマンエラーをベースとした不具合（故障）原因の例を示しているのに対して、図１６は、物理現象をベースとした不具合（故障）原因の例を示している。このうち、図１５のヒューマンエラーをベースとした不具合（故障）原因の例では、上記した「失敗まんだら」に合わせて階層の上位項目（図中で左端に位置する項目）を設定している。

図１７、及び図１８は、ある製品系統に対応する不具合（故障）対策網羅表２１ｆの一例を示す図である。その製品系統の製品やその製造工程に不具合（故障）が発生した場合に、その発生の結果として表れる損害（上記不具合（故障）結果に対応）や、その発生原因（上記不具合（故障）原因に対応）を参照しつつ、そのような不具合（故障）が発生しないようにするために、その不具合（故障）に対する対策（すなわち、不具合（故障）対策）をとる必要がある。不具合（故障）対策網羅表２１ｆは、そのような不具合（故障）対策を階層的に分類して網羅的に定義している。

なお、図１７は、ヒューマンエラーをベースとした不具合（故障）対策の例を示しているのに対して、図１８は、物理現象をベースとした不具合（故障）対策の例を示している。このうち、図１７のヒューマンエラーをベースとした不具合（故障）対策の例では、階層の上位項目（図中で左側に位置し、上端の項目が「原理」「問題」に対応する項目は対策を分類するための項目であり、対策は実現方法の項目に相当する）を設定している。

図４、または図５のＰＰＭＤＢを用いて、その製品に関わる生産システムにおいて発生する不具合に対する対策支援を行う場合には、そのＰＰＭＤＢが有する、製品構造情報と製造工程情報という枠組みを構成する個々の実体（ユニット、または、部品）に対して、その実体に属する属性データを（一般には複数）持たせると共に、それら属性データを用いる各種ロジック（方式）を持たせる。すなわち、ＰＰＭＤＢをベースに、各実体（ユニット、または、部品）、及びその実体の有する各状態に対して、属性データと、各種ロジックを更に追加したＱＡ２−ＫＤＢを作る。そして、対策支援を行う際に参照される情報（例えば、ある不具合現象に対して不具合原因として最も疑わしいもの）を、上記ＱＡ２−ＫＤＢの各種ロジックを用いて算出する。その場合において、本実施形態の不具合対策支援システムのユーザは、以上に説明した各種不具合網羅表を、不具合現象、不具合モード、不具合原因、等に値を設定する際に適宜参照する。

上記した不具合を引き起こしうる潜在的な危険源としてのハザードは、図６のＰＰＭＤＢ同様、このＱＡ２−ＫＤＢ上にも設定することができる。図１９は、そのようなＱＡ２−ＫＤＢ上に設定されたハザードの一例を示す図である。製造の各工程などにおいて、不具合が発生する可能性がある箇所をハザードとして特定し、図中に記載することで、危険源が可視化でき、イメージが得やすくなるという利点がある。なお、このハザードはあくまで概念的なものであり、説明の便宜上、用いるものであることは上記した通りである。

なお、図４がＰＰＭＤＢ２２の概念的な図であるように、図１９もＱＡ２−ＫＤＢ２４に対する概念的な図であるが、参考までに以下に、ＰＰＭＤＢ２２をベースにして、ＱＡ２−ＫＤＢ２４の骨組み（すなわち、まだ属性データの各項目には属性値が登録されておらず、また、ロジックも未定義である状態のＱＡ２−ＫＤＢ）を自動生成する処理について、図２０〜図２３を参照しつつ説明する。

図２０は、その自動生成処理のフローチャートである。
図２０において、ステップＳ１１で、ＰＰＭＤＢ２２からＰＰＭＤＢ情報１００を取得する。この情報の一例は図５のテーブル１００に示されている。

続いて、ステップＳ１２で、取得したＰＰＭＤＢ情報１００を用いて（すなわち、図５のテーブル１００中の構成フラグを参照して）、製品構造情報、各実体を構成する要素（サブ実体）を階層的に抽出する（ブロック、ユニット、部品等）。例えば、図５のテーブル１００に対しては、ユニット１が部品１−１と部品１−２によって構成されているという情報が抽出される。

そして、ステップＳ１３で、抽出された各実体（サブ実体も含む）に対応する実体データモデル雛形（テンプレート）を、不図示のデータベースから取得する。例えば図５では、ユニット１、部品１−１、部品１−２に対応する実体データモデル雛形が取得される。なお、このデータベースは、対象とする製品系統の製品を構成するすべてのブロック、ユニット、部品、等の実体に対応する実体データモデル雛形を保持している。図２１には、ユニット１用の実体データモデル雛形２１１、部品１−１用の実体データモデル雛形２１２の一例が示されている。なお、図示していないが、当然、部品１−２用の実体データモデル雛形も存在している。

そして、ステップＳ１４において、上記各種実体データモデル雛形と、製品の構成（すなわち、製品構造情報）とに基づいて、プロダクトモデル対応のデータ構造２１４を作成する。尚、このプロダクトモデル対応のデータ構造２１４の一例を図２１に示す。図２１に示すように、プロダクトモデル対応のデータ構造２１４では、ステップＳ１３で取得した各種実体データモデル雛形が製品構造情報（この場合は、ユニット１が部品１−１と部品１−２とにより構成されるという情報）に従って配置されている。

また、各実体の各状態に対応する状態データモデル雛形（テンプレート）が予め作成され、不図示のデータベースに保持されている。ステップＳ１５では、このデータベースより、各実体の各状態に対応する状態データモデル雛形２１３を取得し、続くステップＳ１６において、ステップＳ１５で取得した各実体の各状態に対応する状態データモデル雛形２１３を、ＰＰＭＤＢ情報１００に基づいて（すなわち、図５のテーブル１００の状態遷移順１０４を参照しつつ）、ステップＳ１４で取得した各実体データモデル雛形内に順次追加することで、プロダクト・プロセスモデル対応のデータ構造２１５を作成する。

図２２に、このプロダクト・プロセスモデル対応のデータ構造２１５の一例を示す。図において、ユニット１、部品１−１、部品１−２ごとに、対応する状態データモデル雛形が図５の状態遷移順に基づく順に従って追加されている。

なお、以上の説明では、各種テンプレート（実体データモデル雛形、状態データモデル雛形）は、予め作成されていたが、その作成方法について以下で簡単に説明しておく。
まず、実体データモデル雛形の場合は、製品設計情報（知見・ノウハウを含む）から整理・作成する。製品設計情報とは、製品の設計業務に関する情報・知見・ノウハウであり、ユニットまたは部品の機能性、性能、材料（材質）、幾何形状などの仕様情報、業務基準書や品質基準書などの各種基準書（これらはノウハウに相当）、過去の設計不良による不具合情報（現象、原因、対策等）（これらは知見・ノウハウに相当）、等を指している。

また、状態データモデル雛形の場合は、工程設計情報及び生産製造情報（知見・ノウハウを含む）から整理・作成する。工程設計情報・生産製造情報とは、製品を製造するための工程設計業務、製造業務に関する情報・知見・ノウハウであり、ユニットまたは部品の製造方法、条件、工程順、設備、治工具、工作仕様、レイアウトなどの工作仕様情報、業務基準書や品質基準書などの各種基準書（これらはノウハウに相当）、過去の設計不良による不具合情報（現象、原因、対策等）（これらは知見・ノウハウに相当）、生産製造現場からの各種知見・ノウハウ、ポカヨケ対策、等を指している。

以上説明した処理によって、図３のＱＡ２−ＫＤＢ２４の骨組みが生成される。その後、そのＱＡ２−ＫＤＢ２４に対し、各種ロジックを追加する。例えば図２３では、ユニット１、部品１−１、部品１−２のそれぞれに対し、ロジック１とロジック２が追加されている。

ロジック１は、他の実体が、インターフェイスを介して、そのロジック１を有する実体に与えるストレスと、その実体が有するストレングスとを比較することで、相互作用に基づく不具合がこの実体で発生するかどうかを判定するロジックである。ロジック１には、例えばＳＳＭロジックなどがある（具体例については後述する）。なお、ＳＳＭロジックによれば、その実体で不具合が発生する条件は、ストレス＞ストレングスで与えられる。

また、各実体は、図４、図５に示すように、製造工程（「組立」も製造工程に含む）を有する。製造工程は、複数の状態と、それら連続する状態間を結ぶ矢印とによって構成される。各状態（図５の状態コードに相当）はその前の状態（図５の前状態コードに相当）に対して、図５の状態遷移コード１０５で示される状態遷移条件を満たすことによって（すなわち、そのコードに示される種別の作業を行うことによって）、現状態へと遷移する。したがって、現状態で生じる不具合には、前状態と前状態から現状態へのハザード混入を含めた遷移条件が関与してくる。

図２３のロジック２は、そのロジック２を有する実体において、その実体の製造工程における不具合の因果関係を算定するロジックである。
また、本実施形態の不具合対策支援システムでは、図３の登録部１０によって、上記した各属性に対して（属性）値を登録することや、ロジックを新規に定義したり、再定義したりできる。

図２４は、図３の登録部１０の機能の一例を説明する図である。
図２４において、本実施形態の不具合対策支援システムのユーザは、図３の登録部１０を介して、ＱＡ２−ＫＤＢ２４に設定された各属性に対して属性値を設定する。

この属性値の登録は、自動処理ではなく、人間が手作業で行う。本実施形態においては、図に示すように、予め作成されて上記不具合網羅表記憶部２１に格納されている各種網羅表に基づいてマスタテーブル２４１に格納される各種マスタテーブル、すなわち、部位マスタテーブル、現象マスタテーブル、結果マスタテーブル、不具合モードマスタテーブル、原因マスタテーブル、対策マスタテーブル等の内容を、例えばユーザの情報処理端末のディスプレイに一覧表示して、ユーザに必要な項目を選択させることで、属性値の登録が行える。例えば、図示の実体／状態データモデルにおける属性「現象」に対して、属性値を設定する場合には、現象マスタテーブルを表示する。現象マスタテーブルには、具体的な現象、例えば発熱、振動、騒音等が格納されており、これらを一覧表示してユーザに選択させることで、属性「現象」に対する属性値を登録することができる。

更に、各種マスタテーブルから選択した属性値を、図３の知識データ記憶部２３中の知見・ノウハウシートに反映させるようにしてもよい。マスタテーブルから知見・ノウハウシートへの書き込みに際しては、その属性値に対応するコメント等が含まれていてもよい。

また、上記属性だけでなく、他の属性（影響度、等）も含めて、実体／状態データモデルの各属性値を更新することもできる。
ここで、属性値の更新とは、例えば、
・発生頻度（属性）に関する属性値を、２回／月から３回／月に更新
・耐性（ストレングス）（属性）に関する属性値を、−３０℃〜＋５０℃から−２０℃〜＋５５℃に更新
・影響度（属性）に関する属性値を、２から５に更新
等である。

また、図２４において、情報処理端末のユーザに任意のマスタテーブルを選択させてこれを表示し、この表示画面上で、ユーザによって、マスタテーブルの内容を変更、追加、削除等する入力操作を行わせることで、マスタテーブル２４１のメンテナンスを行うこともできる。

図３の不具合対策支援部４０が、知見・ノウハウ蓄積部２０に蓄積された各種情報を用いることによって実現される不具合対策支援機能には、不具合分析支援機能と不具合未然防止支援機能とがある。なお、不具合分析支援機能には、不具合原因追及（支援）機能と不具合影響分析機能とがある。

図２５は、図３の不具合対策支援部４０が行う全体的な処理の流れを、簡単なフローと共に説明する図である。
図２５において、不具合が発生すると、不具合が発生した部位（部品）とその部位に発生した不具合現象とを示す不具合連絡票が例えば現場担当者によって作成される。本システムのユーザ（上記現場担当者が兼ねることもある）は、その不具合連絡票に記載される内容を図３の登録部１０を介して取り入れる（ステップＳ２１）。これにより、不具合が発生した部位に対応する不具合の現象が分かる。そして、ステップＳ２２において、分析を行うことにより、実体（部位）／工程が分かると共に、原因候補がリストアップされる。このようにして得られた、部位、現象、原因を検索キーとして検索を行い、検索結果として、対策候補がリストアップされる。以上の分析結果は、部位、現象、原因、対策の組として体系化される。

なお、ステップＳ２３では、対策検討が行われる。この対策検討においては、上記した対策候補の中からとるべき対策を選定したり、不具合の発生を未然に防止するためにとるべき対策の候補を危険優先度の観点からリストアップしたりする。

図２６は、上記した不具合原因追求支援機能を説明する図である。
図２６（ａ）において、不具合が発生した実体（部品）に対応する不具合モードの網羅的な集合Ａと、その実体に発生した不具合現象に対応する不具合モードの網羅的な集合Ｂとの共通集合をとることによって、その実体（部品）でその不具合現象が発生したことに関連付けられる不具合モードの網羅的な集合Ｃを抽出する。尚、図２６（ｂ）（ｃ）は、図２６（ａ）の説明に対応する各不具合網羅表間の関係を示す図である。図２６（ｂ）を参照すると、不具合が発生した実体（例えば、部位）Ｂ１に対しては、不具合モードＫ１，Ｋ２，Ｋ３がその網羅的な集合として対応しており、また、図２６（ｃ）を参照すると、その実体Ｂ１で発生した不具合現象Ｇ１１に対しては、不具合モードＫ１，Ｋ３が網羅的な集合として対応していることが分かる。そして、不具合原因追求支援機能は、その共通集合である不具合モードＫ１，Ｋ３（これは、上記集合Ｃに対応する）に対応する不具合原因Ｃ１，Ｃ３を、実体Ｂ１で不具合現象Ｇ１１が発生した（あるいは、発生する可能性がある）原因として推定する。

ここで、上記共通集合としての不具合モードＫ１，Ｋ３は、不具合が発生した実体Ｂ１とその実体Ｂ１に発生した不具合現象Ｇ１１とを関連付けている。本実施形態においては、上記共通集合としての不具合モードＫ１，Ｋ３を介することで、実体Ｂ１で不具合現象Ｇ１１が発生する確率を算出している。

図２７は、図２６の不具合（故障）原因追求（支援）機能をより具体的に説明する図である。
図２７に示す表現モデルでは、ユニット１は部品１−１と部品１−２とから構成され、それは、上記したような製品構造情報と製造工程情報とを有しているが、ここではその説明は（上記したことの繰り返しになるので）省略する。

上記したように、製造工程においては、現状態で生じる不具合には、前状態と前状態から現状態へのハザード混入を含めた遷移条件が関与してくる。例えば図において部品１−１で、状態３に対しては状態２が、状態２に対しては状態１が不具合の原因となりうる。つまり、状態３から状態２や状態１への方向は、状態３で発生した不具合の原因を追求する方向を示している。これに対して、状態２や状態１から状態３への方向は、そのような不具合を生じさせうる潜在的な危険源（ハザード）が伝播する方向、あるいは、状態１〜３で発生した不具合が他に影響を及ぼすべく伝播していく方向を示している。図中に「状態遷移による伝播」と表記される矢印の方向は、このハザードの伝播方向に一致している。

なお、一方では、部品はインターフェイスが設定された（インターフェイスの設定は、ユーザが情報処理端末から行う）他の部品からストレスを受けていて、そのストレスがその部品の許容範囲（耐性、ストレングス）を越えた場合に不具合が発生する。なお、図は、部品１−２に不具合が発生した場合を想定している。このため、図中に「相互作用（インターフェイス）による伝播」と表記される矢印の方向は、部品１−１（すなわち、部品１−２から見て他の部品、但し、上記したようにユーザによって予め部品１−１と部品１−２との間にはインターフェイスが設定されている）から部品１−２に向かっている。

したがって、ある部品で不具合が発生した場合、それが、他の部品からのストレスによるものか、それともその部品自体の製造工程に問題があるのかをまず決める必要がある。図中の表現では、まず、相互作用分岐か状態遷移分岐かを決める必要がある。

以下に、不具合（故障）原因追及支援処理の概要を説明する。
まず、可能な不具合（故障）モードの原因脈路の同定を行う。すなわち、各実体について、予めハザード伝播路に沿って実体の状態遷移、及び他の実体から与えられる相互作用により発生しうる不具合（故障）モードを網羅的に定義し、それぞれの影響源から与えられる影響の度合い（影響度（寄与率））と、それらの不具合（故障）モードが発生する可能性を確率的・体系的に同定する。これにより原因脈路が作成される。

そして、上記したそれらの可能な故障モードが実際に発生する頻度を更に加味する。
更に、状態遷移によるストレングスへの影響（何をどの程度）、及び他の実体から与えられた相互作用によるストレスへの影響（何をどの程度）を体系的に記述する。

次に、発生する不具合（故障）モードの原因分析を行う。すなわち、不具合（故障）発生部位からハザード伝播路を逆方向（後方）へ遡って分析を行う。
まず、不具合（故障）現象から原因をストレングスの低下のみによるものか、ストレスの悪化のみによるものか、または、ストレングスの低下とストレスの悪化の両方によるものかを確率的に切り分ける。

ストレングス低下の確率が高い場合、状態分岐遷移に重点を置き、実体の製造過程で発生しうる確率の高い状態遷移における影響源を（確率の高い順に）リストアップする。
他の実体からのストレス悪化の確率が高い場合、相互作用分岐に重点を置き、他の実体で発生しうる確率の高い影響源を（確率の高い順に）リストアップする。

また、両方の場合、実体の製造過程で発生しうる確率の高い状態遷移における影響源と、他の実体で発生しうる確率の高い影響源との双方を（確率の高い順に）リストアップする。

尚、他の実体からのストレス悪化の確率が高い場合や、ストレングス低下の確率が高い場合で状態遷移が実体から生じる組立工程の場合には、その他の実体や、状態遷移が生じる実体を不具合（故障）モードと仮定し、上記した不具合（故障）モードの分析を繰り返し行う。

以下では、上記した不具合（故障）原因追求（支援）機能について、図２８、及び図２９のフローチャートを参照しつつ説明する。
まず、不具合の原因追求処理に先立って、本システムのユーザは、現場担当者から不具合連絡票を受け取る。この不具合連絡票には、不具合が発生した製品、その製品における不具合が発生した部位、その部位で発生した不具合（故障）現象、等が記載されている。そして、ステップＳ１０１において、ユーザは情報端末装置から、その不具合連絡票に記載される不具合が生じた製品の系統名を入力する。この系統名の入力に対して、ステップＳ１０２において、あらゆる製品系統に対してデータとして保持されているマスタテーブル群、ＱＡ２−ＫＤＢ群の中から入力された系統名に対応する製品のマスタテーブル、ＱＡ２−ＫＤＢが選択される（対象製品系統の絞り出しが行われる）。

続くステップＳ１０３では、今回対象となる製品系統に対する部位マスタテーブルが読み込まれ、ユーザによって、その不具合連絡票に記載される不具合部位が選択される。そして、ステップＳ１０４において、対象製品系統のＱＡ２−ＫＤＢ（属性・属性値）が読み込まれ、ユーザによって、このＱＡ２−ＫＤＢから不具合が発生した部位が選択される。この際、不具合網羅表間のリンク関係（このリンクも、自動処理ではなく、人間が手作業で行うものである）に基づいて、対象不具合部位でのありうる不具合モードの一覧（図２６（ｂ）では、Ｋ１，Ｋ２，Ｋ３）、及びそれに対応する不具合現象の一覧（図２６（ｃ）では、Ｇ１１，Ｇ１２，Ｇ２１，Ｇ２２）が表示される。

続いて、ステップＳ１０５において、ユーザによって、この一覧中に今回対象となる不具合現象に対応（一致）する不具合現象があるかどうかが判定される。図２６を例にとると、今回対象となる不具合現象が、図２６（ｃ）の一覧中のＧ１１，Ｇ１２，Ｇ２１，Ｇ２２のいずれかに一致するかユーザによって判定される。

このように、ステップＳ１０５において、表示された不具合現象の一覧中に、対象不具合現象に対応する不具合現象が含まれていないと判定された場合は、ステップＳ１０６において、ユーザによって、現象マスタテーブルが開かれ、ステップＳ１０７で、ユーザによって、現象マスタテーブル中に、対象不具合現象が有るかどうかが判定される。無いと判定された場合、ステップＳ１０８において、ユーザによって、現象マスタテーブルがその対象不具合現象をデータとして追加するようにメンテナンスされ、その後、ステップＳ１０９において、ユーザによって、その追加した不具合現象が選択（登録）される。また、現象マスタテーブル中に有ると判定された場合、直ちに、上記ステップＳ１０９の処理が行われる。

その後、ステップＳ１１０において、ステップＳ１０９で登録された不具合現象（属性・属性値）をキーにしてＱＡ２−ＫＤＢの不具合モード（右側）（属性・属性値）より、その不具合現象（属性・属性値）と対応する不具合モード（属性・属性値）を特定する。なお、ステップＳ１０５において、表示された不具合モードの一覧中に、対象不具合現象に対応する不具合現象が含まれていると判定された場合は、直ちに上記ステップＳ１１０が実行される。

続いて、図２９に移行し、ステップＳ１１１において、ステップＳ１１０で特定された不具合モード（属性値）に関連するストレス事象（左側）（すなわち、不具合を発生した部位が、インターフェイスを有する他の部位から入力として受け取るストレス事象）を抽出する。

そして、ステップＳ１１２において、ステップＳ１１１で抽出されたストレス事象のそれぞれに対応するストレングスを更に抽出し、不具合発生時のストレス状況について、利用者（不具合連絡票を作成した現場担当者等）に確認する。この確認の結果として、ユーザによって、ストレスデータの入力、または、提示したストレス・ストレングスの比較結果（Ｙｅｓ／Ｎｏ／不明）のチェックが行われる。なお、比較結果（不明）は、利用者からの確認がとれず、不具合発生時のストレスデータが不明となるような場合等にチェックされる。

そして、このようにして抽出された（今回の不具合に関わる）全てのストレス項目について、以下のステップＳ１１３、及びＳ１１４の処理を実行する。
すなわち、まず、ステップＳ１１３において、ストレスがストレングスで示される許容範囲を越えるか（すなわち、ストレス＞ストレングスであるか）が判定される。もし、許容範囲を越えれば、ステップＳ１１４において、そのストレス事象につながる実体を新たな不具合部位として設定する。

すべてのストレス項目について、ステップＳ１１３、及びＳ１１４の処理を終了したならば、続いて、ステップＳ１１５へ進み、上記ステップＳ１１４で設定した新たな不具合部位（実体）がないかを判定する。もしあれば、ステップＳ１１６において、ステップＳ１１４で設定された不具合部位を原因分析を行う新たな対象（不具合部位）として設定し、ステップＳ１０４に戻って、上記ステップＳ１０４〜Ｓ１１５を繰り返す。

一方、ステップＳ１１４において、新たな不具合部位の設定がなければ、ステップＳ１１７に進む。
ステップＳ１１７では、ステップＳ１１０で特定された不具合モードを基に、ステップＳ１１１で抽出されたストレスに関連する不具合モードを除いて、原因となりうる残りの事象（左側）について抽出し、その抽出されたそれぞれの事象の対象不具合モードへの影響度（寄与率）をその対象不具合モードに関わるロジック（ＦＴＡロジック等）、及び末端事象の発生確率から算出している。

そして、ステップＳ１１８において、ステップＳ１１７で抽出された事象を（対象不具合の）原因（候補）とし、更に、（ステップＳ１１７で）算出された対応する影響度（寄与率）をその原因（それら原因候補）が真である確率（その原因が真因となる確率）として、その原因（それら原因候補）と対応付けるようにして、その原因（要因）候補リストを、情報処理端末のディスプレイ上に一覧表示する。あるいは、この一覧表示した結果に対応する内容をＱＡ２−ＫＤＢに格納する。なお、この一覧表示は、この原因追求支援処理の（分析）結果であり、「原因（要因）候補リスト」と呼ばれている。また、確率順にソートされて出力されることから「原因の確率（寄与率）順リスト」とも呼ばれている。

図３０は、（対象不具合の）原因追求支援処理において原因（要因）候補リストが出力される様子を説明する図である。図に示すように、この原因（要因）候補リスト上の各原因項目に項目「リンク」を設けるようにしてもよい。このリンク情報を参照する（例えば、画面上でそのリンクを指定する）ことにより、その原因項目と関連する資料やデータ類を参照することができる。

以下に、図３１〜図３７を参照しつつ、上記した原因追求支援処理をより具体的に説明する。
図３１は、導板と台金を部品として構成されるユニットに対応するＱＡ２−ＫＤＢの構築例を示す図である。

図３１において、ユニット１は、部品１−１（導板）と部品１−２（台金）とにより構成され、各実体（ユニット１、部品１−１、部品１−２）は、ＳＳＭロジックと、ＦＴＡロジックとを有している。

図３２は、図３１のユニット１を構成する部品１−１（導板）の実体／状態データモデルを、その部品１−１に適用されるＳＳＭメソッド（ロジック）と共に示した図である。
図３２において、部品１−１（導板）は、インターフェイスを有し、かつ、隣接する他の部品（不図示）の発熱等によって、その他の部品（不図示）からストレス１（ストック温度）、ストレス２（ストック湿度）、ストレス３（ストック期間）を受けている。

上記した図２８、図２９のフローとの関係では、この部品１−１（導板）で発生した不具合現象５（「表面に錆びが発生する」）に関連付けられる不具合モードとして、不具合モード５（錆び）がステップＳ１１０で取得され、この不具合モード５（錆び）に関連するストレス事象（左側）として、ストレス１（ストック温度）、ストレス２（ストック湿度）、ストレス３（ストック期間）がステップＳ１１１で抽出される。この部品１−１の不具合モード５（錆び）のＳＳＭメソッドロジックでは、条件式：（ストレス１＞ストレングス１）＆（ストレス２＞ストレングス２）＆（ストレス３＞ストレングス３）が真であれば、不具合モード５（錆び）が真に設定される。なお、ストレングス１、ストレングス２、ストレングス３は、それぞれ、対錆温度閾値、対錆湿度閾値、対錆期間閾値を示す属性であり、ここでは、３０℃、８５％、１０時間という値がそれぞれ属性値として格納されている。

ユーザは、不具合発生時のストレス状況の確認を利用者に対して行い、その結果として、ストレスが上記各閾値を越えるかどうかが判定される。
図３３は、図３１のユニット１を構成する部品１−１（導板）の実体／状態データモデルを、その部品１−１に適用されるＦＴＡメソッド（ロジック）と共に示した図である。

図３３において、部品１−１（導板）の実体／状態データモデルは、部品１−１（導板）の製造工程の各状態の各不具合モードに対応して、その不具合モードを出力とする複数のＦＴＡメソッドロジックを有している。

図において、不具合モード２（反り）のＦＴＡメソッドは、製造条件（部材送り方向不良）、製造条件（反り矯正力不良）、環境条件（巻き癖大）を末端事象とし、以下の論理式によって、不具合モード２（反り）に値を設定する。
論理式：（部材送り方向不良）＋（反り矯正力不良）・（巻き癖大）
また、不具合モード６（反り）のＦＴＡメソッドロジックは、ストック条件（重ね置きによる外力発生）、不図示の前段のＦＴＡが出力する不具合モード、を末端事象とし、以下の論理式によって、不具合モード６（反り）に値を設定する。
論理式：（重ね置きによる外力発生）＋（前段のＦＴＡの出力する不具合モード）
なお、図では、不具合モード２（反り）はプレス加工工程に、不具合モード６（反り）はストック工程に、それぞれ関連する不具合モードとなっている。

本実施形態では、このように、ある状態に関連する不具合モードのメソッドロジックは、その状態の前状態に関連する不具合モードを左側（すなわち、入力側）に有する構成とすることもできる。したがって、このような前段の不具合モードを入力するメソッドロジックが数段続いた場合、全体のイメージとしては、大きな（トップ事象から見て、末端事象に至るまでのツリーの階層が深い）故障木を有することになる。

上記した図２８、図２９のフローとの関係では、この部品１−１（導板）で発生した不具合現象６（「反りが０〜０．２ｍｍの範囲外となる」）に関連付けられる不具合モードとして、不具合モード６（反り）がステップＳ１１０で取得され、この不具合モード６（反り）に関連する事象（不具合モードも含む）（左側）として、上記したストック条件（重ね置きによる外力発生）、前段のＦＴＡの出力する不具合モードが、またその前段のＦＴＡに関連する事象（左側）として、・・・という具合に因果関係の連鎖を遡っていくことによって、最終的には、不具合モード２（反り）のＦＴＡに関連する事象（左側）として、製造条件（部材送り方向不良）、製造条件（反り矯正力不良）、環境条件（巻き癖大）までがステップＳ１１７で取得され、これらの各事象を含む故障木によって、不具合モード６（反り）に対する各事象の影響度（原因事象の結果事象への寄与率）が（逆）算出される。

故障木における原因事象の結果事象への寄与率の算出方法としては、様々な方法があるが、それらの方法につき、以下、図３４〜図３５を参照しつつ説明する。
図３４は、発生確率（寄与率）を算出する対象としての故障木の一例を示す図である。

図３４において、トップ事象Ｆは、末端事象Ｆ１，Ｆ２，Ｆ３から以下の論理式によって求められる。
論理式：Ｆ＝Ｆ１＋Ｆ２・Ｆ３
故障木において事象の発生確率を算出する方法が知られている。

例えば、互いに排反ではない事象Ｅ，Ｆの発生確率Ｐ（Ｅ），Ｐ（Ｆ）の論理和Ｐ（Ｅ∪Ｆ）は、下記非特許文献５に記載されるように、以下の式で与えられる。
Ｐ（Ｅ∪Ｆ）＝Ｐ（Ｅ）＋Ｐ（Ｆ）−Ｐ（Ｅ∩Ｆ）
山本周行著「統計学要論」昭和３９年４月、明文書房上式に対応する故障木、すなわち、トップ事象Ａ（発生確率Ｐ（Ａ））が末端事象Ｅ１（発生確率Ｐ（Ｅ１））と末端事象Ｅ２（発生確率Ｐ（Ｅ２））との論理和からなり、事象Ｅ１とＥ２が独立事象である場合、Ｐ（Ｅ∩Ｆ）＝Ｐ（Ｅ）Ｐ（Ｆ）が成り立つので、事象Ａの発生確率Ｐ（Ａ）は以下のようになる。Ｐ（Ａ）＝Ｐ（Ｅ１）＋Ｐ（Ｅ２）−Ｐ（Ｅ１）Ｐ（Ｅ２）本実施形態においては特に、上記した不具合モードが一般には排反事象になっていないことを考慮し、上記故障木の事象Ｅ１、Ｅ２の結果事象への寄与率ＰＡ（Ｅ１）、ＰＡ（Ｅ２）を、以下の式により算出する構成としている。ＰＡ（Ｅ１）＝（１−Ｐ（Ｅ２）／２）Ｐ（Ｅ１）／Ｐ（Ａ）ＰＡ（Ｅ２）＝（１−Ｐ（Ｅ１）／２）Ｐ（Ｅ２）／Ｐ（Ａ）ここで、末端事象（原因事象）Ｅ１、Ｅ２が同時に発生することがあっても（すなわち、Ｐ（Ｅ１∩Ｅ２）＝Ｐ（Ｅ１）Ｐ（Ｅ２）≠０であっても）、ＰＡ（Ｅ１）＋ＰＡ（Ｅ２）＝１、が常に成り立つ、つまり、すべての末端事象（原因事象）について、そのトップ事象（結果事象）への寄与率をすべて合計すると常に「１」となるのが、本実施形態の構成の特徴であり、直感的に分かり易くなっている。

本実施形態においては、上式に示されるように、互いに排反事象とは限らない、複数の原因事象の論理和から結果事象（Ａ）が導かれる構造をツリー構造が示す場合に、その結果事象（Ａ）の発生確率をそれら複数の原因事象の発生確率で表した式における、それら複数の原因事象の発生確率の２つ以上の積により構成される項（Ｐ（Ｅ１）Ｐ（Ｅ２））を、それら複数の原因事象の発生確率の２つ以上に所定の割合で分配するようにして（ここでは等分して）、その原因事象の結果事象に対する寄与率を算出している。

なお、一般に原因事象Ｅｉが排反事象とは限らず、Ａ＝Ｅ１∪・・・∪Ｅｎの場合に、事象Ｅｉの結果事象に対する寄与率ＰＡ（Ｅｉ）とは、結果事象Ａが発生した場合に、それが原因事象Ｅｉの寄与により発生した割合を、各原因事象Ｅｉに対するその合計値が１（１００％）となるように定式化したものである。

更に、一例を示すと、事象Ａ＝Ｅ１∪Ｅ２∪Ｅ３の場合、
Ｐ（Ａ）＝Ｐ（Ｅ１）＋Ｐ（Ｅ２）＋Ｐ（Ｅ３）−Ｐ（Ｅ１）Ｐ（Ｅ２）−Ｐ（Ｅ１）Ｐ（Ｅ３）−Ｐ（Ｅ２）Ｐ（Ｅ３）＋Ｐ（Ｅ１）Ｐ（Ｅ２）Ｐ（Ｅ３）
ＰＡ（Ｅ１）＝（１−Ｐ（Ｅ２）／２−Ｐ（Ｅ３）／２＋Ｐ（Ｅ２）Ｐ（Ｅ３）／３）Ｐ（Ｅ１）／Ｐ（Ａ）
ＰＡ（Ｅ２）＝（１−Ｐ（Ｅ１）／２−Ｐ（Ｅ３）／２＋Ｐ（Ｅ１）Ｐ（Ｅ３）／３）Ｐ（Ｅ２）／Ｐ（Ａ）
ＰＡ（Ｅ３）＝（１−Ｐ（Ｅ１）／２−Ｐ（Ｅ２）／２＋Ｐ（Ｅ１）Ｐ（Ｅ２）／３）Ｐ（Ｅ３）／Ｐ（Ａ）
ＰＡ（Ｅ１）＋ＰＡ（Ｅ２）＋ＰＡ（Ｅ３）＝１
となる。

一般には、Ａ＝Ｅ１∪・・・∪Ｅｎの場合、
Ｐ（Ａ）＝Σ _{ｉ＝１・・・ｎ}Ｐ（Ｅｉ）＋（−１）^１Σ _{ｉ，ｊ∈１・・・ｎ，ｉ＜ｊ}Ｐ（Ｅｉ）Ｐ（Ｅｊ）＋・・・＋（−１）^ｎ−２Σ _{ｉ，ｊ，・・・，ｋ∈１・・・ｎ，ｉ＜ｊ＜・・・＜ｋ}Ｐ（Ｅｉ）Ｐ（Ｅｊ）・・・Ｐ（Ｅｋ）＋（−１）^ｎ−１Π _{ｉ＝１・・・ｎ}Ｐ（Ｅｉ）
ＰＡ（Ｅｉ）＝（１−（−１）^１Σ_{ｉ，ｊ∈１・・・ｎ，ｉ＜ｊ}Ｐ（Ｅｉ）Ｐ（Ｅｊ）／２＋・・・＋（−１）^ｎ−２Σ _{ｊ，・・・，ｋ∈１・・・ｎ，ｊ＜・・・＜ｋ}Ｐ（Ｅｊ）・・・Ｐ（Ｅｋ）／（ｎ−１）＋（−１）^ｎ−１Π _{ｉ＝１・・・ｎ}Ｐ（Ｅｉ）／ｎ）Ｐ（Ｅｉ）／Ｐ（Ａ）
で与えられる。

以上に説明した式によれば、各末端事象の発生確率（上記Ｐ（Ｅｉ））が既知であれば、それを用いることで、結果事象に対する各末端事象の寄与率ＰＡ（Ｅｉ）を算出することができる。しかし、すべての末端事象について発生確率が分かっていないこともある。そのような場合には、故障木の構造から末端事象の構造重要度を算出する方法と、すべての末端事象の事前確率を等しいものとして確率重要度を算出する方法を用いることができる。

まず、構造重要度について説明する。
図３５は、図３４の故障木に対応するテーブルであり、構造重要度を算出する際に用いるテーブルである。

このテーブルにおいて、頂上事象とは、図３４のトップ事象Ｆを指している。そして、事象Ｆｉの構造重要度Ｉｓ（Ｆｉ）は以下の式により求められる。
Ｉｓ（Ｆｉ）＝ｎｓ（Ｆｉ）／２^ｎ−１（ｎは末端事象Ｆｉの数）
ここで、ｎｓ（Ｆｉ）は、末端事象Ｆｉが０から１に変化するときに頂上事象Ｆも０から１に変化する回数（他の末端事象Ｆｊ（ｉ≠ｊ）は変化しない）である。

例えば事象Ｆ１については、状態番号１から５、２から６、３から７、がこの条件を満たしており、ｎｓ（Ｆ１）＝３で与えられるので、構造重要度Ｉｓ（Ｆ１）＝３／４となる。同様に、Ｉｓ（Ｆ２）＝Ｉｓ（Ｆ３）＝１／４となる。ＡＮＤゲートを介さずに頂上事象Ｆに達する事象Ｆ１の重要度が大きいという期待される結果が得られる。

次に、確率重要度について説明する。
確率重要度とは、ｉ番目の原因事象Ｆｉが頂上事象Ｆに与える影響の度合いを定量化したものである。事象Ｆｉの確率重要度ΔＦ（Ｆｉ）は以下の式で与えられる。

ΔＦ（Ｆｉ）＝Ｆ（Ｆｉ＝１）−Ｆ（Ｆｉ＝０）
ここで、重要度を算出する末端（原因）事象Ｆｉ以外の末端（原因）事象Ｆｊ（ｉ≠ｊ）の発生確率はすべて所定値（ここでは０．１）に設定され、事象Ｆｉについて、確率重要度ΔＦ（Ｆｉ）が算出される。

例えば事象Ｆ１については、Ｆ（Ｆ１＝１）は、末端事象Ｆ１，Ｆ２，Ｆ３の発生確率をそれぞれ、１，０．１，０．１としたときの頂上事象Ｆの発生確率であり、同様に、Ｆ（Ｆ１＝０）は、末端事象Ｆ１，Ｆ２，Ｆ３の発生確率をそれぞれ、０，０．１，０．１としたときの頂上事象Ｆの発生確率である。これより、末端事象Ｆ１の確率重要度ΔＦ（Ｆ１）は次式で与えられる。
ΔＦ（Ｆ１）＝Ｆ（Ｆ１＝１）−Ｆ（Ｆ１＝０）＝１−（０．１×０．１）＝０．９９（７２．３％）
同様にして、ΔＦ（Ｆ２）、ΔＦ（Ｆ３）は次式で与えられる。
ΔＦ（Ｆ２）＝Ｆ（Ｆ２＝１）−Ｆ（Ｆ２＝０）＝０．１＋０．１×１−（０．１×（０．１×１））＝０．１９（１３．９％）
ΔＦ（Ｆ３）＝Ｆ（Ｆ３＝１）−Ｆ（Ｆ３＝０）＝０．１＋１×０．１−（０．１×（１×０．１））＝０．１９（１３．９％）
なお、以上説明した不具合の原因追求支援処理における、原因（要因）候補リストの出力の仕方としては、必ずしも各末端事象に対応して確率順に出力する必要はない。

図３６は原因追求支援処理における原因（要因）候補リストの出力例を示す図である。
図３６（ａ）に示す故障木は、末端事象Ｅ１、Ｅ２、Ｅ３、Ｅ４と結果事象Ｙとを有する。これらの関係は次の論理式で与えられる。
Ｙ＝（Ｅ１＋Ｅ２）・Ｅ３＋Ｅ４
＝Ｅ１・Ｅ３＋Ｅ２・Ｅ３＋Ｅ４
結果事象Ｙを、論理和（＋）を含まない各項の論理和で表した上式におけるその各項を、原因（要因）候補リストの各項目に対応させてもよい。図３６（ｂ）を参照すると、事象Ｅ４、Ｅ１・Ｅ３、Ｅ２・Ｅ３の各事象について影響度が確率順にリストアップされている。

図３７は、不具合（故障）影響分析機能を具体的に説明する図である。
図３７に示す表現モデルでは、ユニット１は部品１−１と部品１−２とから構成され、それは、上記したような製品構造情報と製造工程情報とを有しているが、ここではその説明は（上記したことの繰り返しになるので）省略する。

なお、一方では、部品はインターフェイスが設定された（インターフェイスの設定は、ユーザが情報処理端末から行う）他の部品からストレスを受けていて、そのストレスがその部品の許容範囲（耐性、ストレングス）を越えた場合に不具合が発生する。なお、図は、部品１−１に不具合が発生した場合を想定している。このため、図中に「相互作用（インターフェイス）による伝播」と表記される矢印の方向は、部品１−１から部品１−２（すなわち、部品１−１で発生した不具合の影響が及ぶ部品）に向かっている。

したがって、ある部品で不具合が発生した場合、その部品とインターフェイスを有する他の部品のストレスへの影響が支配的か、それともその不具合が発生した部品（を用いる）の次の製造過程への影響が支配的かをまず決める必要がある。図中の表現では、まず、相互作用分岐か状態遷移分岐かを決める必要がある。

以下に、不具合（故障）影響分析（支援）処理の概要を説明する。
まず、可能な不具合（故障）モードの影響脈路の同定を行う。すなわち、各実体について、予めハザード伝播路に沿って実体の状態遷移、及び他の実体から与えられる相互作用により発生しうる不具合（故障）モードを網羅的に定義し、それぞれの影響源から与えられる影響の度合い（影響度）と、それらの不具合（故障）モードが発生する可能性を確率的・体系的に同定する。これにより影響脈路が作成される。

そして、上記したそれらの可能な故障モードの重要度、実際の発生頻度を更に加味する。
更に、状態遷移によるストレングスへの影響（何をどの程度）、及び他の実体から与えられる相互作用によるストレスへの影響（何をどの程度）を体系的に記述する。

次に、発生する不具合（故障）モードの影響分析を行う。すなわち、不具合（故障）発生部位からハザード伝播路を順方向（前方）に分析していく。
まず、不具合（故障）現象から影響をストレングスの低下のみによるものか、ストレスの悪化のみによるものか、または、ストレングスの低下とストレスの悪化の両方によるものかを確率的に切り分ける。

ストレングス低下の確率が高い場合、状態遷移分岐に重点を置き、実体の次の製造過程で発生しうる確率の高い影響（結果）を（確率の高い順に）リストアップする。
他の実体へのストレス悪化の確率が高い場合、相互作用分岐に重点を置き、他の実体で発生しうる確率の高い影響（結果）を（確率の高い順に）リストアップする。

また、両方の場合、実体の次の製造過程で発生しうる確率の高い影響（結果）と、他の実体で発生しうる確率の高い影響（結果）との双方を（確率の高い順に）リストアップする。

なお、他の実体へのストレス悪化の確率が高い場合や、ストレングス低下の確率が高い場合で状態遷移が実体から生じる組立工程の場合には、その他の実体や、状態遷移が生じる実体を不具合（故障）モードと仮定し、上記した不具合（故障）モードの影響分析を繰り返し行う。

なお、不具合（故障）影響分析（支援）機能については、図３８のフローチャートを参照しつつ説明する。このフローは、不具合（故障）原因追求機能について説明した図２９のフローに対応し、影響分析における相違点を記載したものである。なお、不具合（故障）原因追求機能について説明した図２８のフローに対応する処理は、影響分析においても同じであるので省略する。また、以下の説明においては、図２９との相違点を主に説明する。

まず、相互作用分岐における変更点は以下のようである。
不具合影響分析処理を行う場合でも、ステップＳ１０１〜ステップＳ１１０までの処理は、図２８の不具合原因追求処理の場合と同じである。

ステップＳ１１０に続くステップＳ２１１において、ステップＳ１１０で特定された不具合モード（属性値）に関連するストレス事象（右側）（すなわち、不具合を発生した部位が、インターフェイスを有する他の部位へ出力するストレス事象）を抽出する。

このため、ステップＳ２１１の次のステップである、ステップＳ１１２において、ステップＳ２１１で抽出されたストレス事象のそれぞれに対応するストレングスを抽出した場合、そのストレングスは、不具合を発生した部位からインターフェイスを介してストレスを受ける他の部位の属性となる。

次に状態遷移分岐における変更点は以下のようである。
図２９のステップＳ１１５の次のステップであるステップＳ２１７では、ステップＳ１１０で特定された不具合モードを基に、ステップＳ２１１で抽出されたストレス（右側）に関連する不具合モードを除いて、影響結果となりうる残りの事象（右側）について抽出し、その抽出されたそれぞれの事象の対象不具合モードからの影響度（確率）をその対象不具合モードに関わるロジック（ＦＴＡロジック等）、及び末端事象の発生確率から算出する。

そして、ステップＳ２１８において、ステップＳ２１７で抽出された事象を（対象不具合の）影響結果（候補）とし、更に、（ステップＳ２１７で）算出された対応する影響度（確率）をその影響結果（それら影響候補）が真である確率として、その影響（それら影響候補）と対応付けるようにして、その影響候補リストを、情報処理端末のディスプレイ上に一覧表示する。あるいは、この一覧表示した結果に対応する内容をＱＡ２−ＫＤＢに格納する。なお、この一覧表示は、影響が及ぶ範囲をも示すことから、「影響範囲と影響度候補の（確率順）リスト」とも呼ばれている。

なお、影響分析を行う場合は、原因追及を行う場合とは、逆方向に故障木を進む。すなわち、影響分析においては、末端事象からトップ事象の方向に故障木を分析する。この場合、不具合が発生した実体の対応する不具合モードは、発生確率を１に設定して、その故障木での分析を行う。例えば、その不具合モードがＯＲゲートの入力の１つであれば、そのＯＲゲートの出力は１となり、また、その不具合モードが、２入力ＡＮＤゲートの入力の１つであれば、そのＡＮＤゲートの出力は他方の入力値となる。

なお、以上においては、実体／状態データモデル（ＱＡ２−ＫＤＢ）に追加するロジックとしては、ＳＳＭ、ＦＴＡロジックであったが、その他のロジックを追加することもできる。

以下では、ＦＭＥＡロジックを、この追加するロジックとして考える。ＦＭＥＡロジックは、不具合未然防止支援のために用いられるロジックである。したがって、実際に不具合が発生した後で、その発生した不具合に対して、対策を考えるのではなく、不具合が起こる前に、製品（より広くは、その製品に関わる生産システム全体）に内在する危険因子を危険優先度として算出し、この危険優先度を不具合未然防止支援のために用いている。

図３９は、不具合未然防止支援処理のフローチャートである。
図３９において、ステップＳ３０１において、ユーザによって、情報端末装置から、今回ターゲットとする製品系統名が入力されると共に、ＦＭＥＡが起動される。そしてこの系統名の入力に対して、ステップＳ３０２において、あらゆる製品系統に対してデータとして保持されているマスタテーブル群、ＱＡ２−ＫＤＢ群の中から入力された系統名に対応する製品のマスタテーブル、ＱＡ２−ＫＤＢが選択される（対象製品系統の絞り出しが行われる）。

続いて、ステップＳ３０２で選択された製品のすべての実体／工程に対して、以下のステップＳ３０３〜ステップＳ３０５の処理が繰り返される。
すなわち、ステップＳ３０３において、対象実体／工程のＦＭＥＡメソッドより、その対象実体／工程内の各不具合モードの危険優先数（危険優先度）を算出する。図４０は、この様子を説明する図である。図において、今回対象となる実体／工程内には、ｎ個の不具合モード（不具合モード１〜不具合モードｎ）が含まれている。各不具合モードでは、その不具合モードの危険優先数を下記の式に基づき算出している。
危険優先数＝発生頻度×影響度×検出難易度
ここで、各項目の定義は、
・発生頻度・・・所定期間内（例えば１ヶ月内）にその不具合が発生する回数
・影響度・・・その不具合が発生した場合に生産システムが受ける影響の度合い
・検出難易度・・・その不具合を検出することの難易度
で与えられる。

続いてステップＳ３０４において、ステップＳ３０３で算出された各不具合モードの危険優先数を大小順でソートし、テーブルに格納する。なお、このテーブルは、実体／工程毎の各不具合モードの危険優先数を大小順にリストアップしたものであり、実体／工程内の各不具合モードの危険優先数（大小順）リストと呼ばれる。

続いてステップＳ３０５において、ステップＳ３０４で処理された実体／工程の各不具合モードを対応する危険優先数で全システム的に大小順でソートし、テーブルに格納する。なお、このテーブルは、全システム内における各不具合モードの危険優先数を大小順にリストアップしたものであり、全システム内の各不具合モードの危険優先数（大小順）リストと呼ばれる。

上記ステップＳ３０３〜ステップＳ３０５の処理が、対象製品のすべての実体／工程に対して行われると、ステップＳ３０６に進む。ステップＳ３０６では、情報処理端末のディスプレイ上に表示された「実体／工程別」、「システム一括」の項目からユーザによって、いずれかの項目が選択される。

続くステップＳ３０７では、ステップＳ３０６で選択された項目が「システム一括」であるかどうかが判定される。もし、「システム一括」が選択されていれば、ステップＳ３０８に進み、上記した全システム内の各不具合モードの危険優先数リストを出力装置に出力する。一方、「実体／工程別」が選択されていれば、ステップＳ３０９に進む。

ステップＳ３０９では、ユーザによって、実体／工程別表示を行うかどうかが決定される。行わない場合には、一連の不具合未然防止支援処理を終了する。一方、行う場合には、ステップＳ３１０において、対象とする製品系統の部位マスタテーブルから、ユーザによって、ディスプレイ上で対象とする実体／工程が選択される。

続くステップＳ３１１では、対象製品系統のＱＡ２−ＫＤＢに基づいて、選択された実体／工程に対応する実体／工程内の各不具合モードの危険優先数リストを出力装置に出力する。そして、ステップＳ３１２で他の実体／工程を表示するかどうかがユーザによって選択される。もし、表示するなら、ステップＳ３１０に戻り上記処理が繰り返される。もし、表示しないなら、一連の不具合未然防止支援処理を終了する。

なお、ステップＳ３０８やＳ３１１で出力されるリストは、対策候補リストとも呼ばれている。
図４１は、上記した対策候補リストのメンテナンス機能を説明する図である。

図４１において、図４０のステップＳ３０８やＳ３１１での出力結果として、対策候補リストが確率順にリストアップされる。
ステップＳ３１で、ユーザによって、それらリストアップされた対策に対応する有効な対策があるかが判定される。もし、有効な対策があれば（Ｓ３１でＹＥＳ）、ステップＳ３２でその有効な対策を選択し、ＱＡ２−ＫＤＢ２４中の属性「対策」に登録する。もし、有効な対策がなければ（Ｓ３１でＮＯ）、ステップＳ３３で、ユーザによって、その有効な対策がマスタテーブル内にあるかどうかが判定される。もし、マスタテーブル内にあれば（Ｓ３３でＹＥＳ）、Ｓ３４に進み、マスタテーブルから有効な対策が選択され、ＱＡ２−ＫＤＢ２４中の属性「対策」に登録する。また、もし、マスタテーブル内になければ（Ｓ３３でＮＯ）、Ｓ３５に進み、必要な対策（文）をマスタテーブルに追加してからステップＳ３４に進み、マスタテーブルから有効な対策を選択し、ＱＡ２−ＫＤＢ２４中の属性「対策」に登録する。

図４２は、上記した不具合原因追求処理、不具合影響分析処理、及び不具合未然防止支援処理の結果としての候補リストの出力例を示す図である。図において、不具合の原因究明に対しては原因（要因）候補リストが、不具合の影響把握に対しては影響範囲（結果）と影響度候補リストが、不具合の未然防止支援（対策検討）に対しては対策候補リストが、それぞれ（確率（寄与率）順にソートされて）出力されている。

図４３は、（ある実体に対応する）実体／状態データモデルの一例を示す図である。
図４４は、図４３の実体／状態データモデルの記述に利用される不具合原因網羅表を示す図である。なお、本実施形態においては、実体／状態データモデルの属性の中で、原因属性は、不具合原因網羅表を用いて属性値を記述している。

例えば図４３の実体／状態データモデルの左側の属性の中で、加工製造方式（不良）は原因属性であり、図４５の不具合原因網羅表を用いて属性値が記述されている。なお、「加工製造方式（不良）」という表記は２つの情報を有する。１つは属性「加工製造方式」が属性値「・・・」であるという情報であり、もう１つは原因属性が属性値「加工製造方式（不良）」であるという情報である。

また、図４５は図４３の実体／状態データモデルの記述に利用される不具合部位網羅表を示す図である。例えば図４３の実体／状態データモデルの属性「リム部」「バブ部」「スポーク部」は、図４５の不具合部位網羅表中の項目「リム部」「バブ部」「スポーク部」を用いて記述されている。

なお、（例えば図４３などに示す）実体／状態データモデル中の属性であって、上記した各種不具合網羅表を用いて記述するもの以外のものには、参考、補足情報として設計や製造上のノウハウ情報を設計書、規格書、基準書、等を用いて記述するものや、知見・ノウハウを有するドキュメントへのリンク情報などがある。

なお、以上の説明は、各種データを用いて行ってきたが、ここで、参考までに、それら各種データが実在する形態を示す。図４６は、その各種データの実在の仕方を示す図である。図に示すように、各種データは、製品設計情報に関するもの、工程設計情報に関するもの、生産製造情報に関するもの、に大別される。そして、いずれのデータもその存在する形態としては、人の頭脳にある知見・ノウハウ、電子化または非電子化の図面・帳票情報、ＤＢ化された情報、のいずれか、またはそれらの任意の組み合わせとして存在している。

本発明は、加工組立型の生産システムなどの生産システムの設計支援に適用できる。

生産システムにおける、製品が市場に投入されるまでのフェーズの流れを説明する図である。図１の生産システムに対応する不具合処理の業務フローを示す図である。本発明の一実施形態の生産システムにおける不具合対策支援システムの構成を示すブロック図である。ＰＰＭＤＢの概念的な構造を示す図である。図４の表現モデル（ＰＰＭＤＢ）に対応するテーブルを示す図である。図４の表現モデル（ＰＰＭＤＢ）に対して、ハザードとインターフェイス情報を設定した一例を示す図である。４個の部品から構成されるユニットの表現モデルを示す図である。図３の不具合網羅表記憶部に記憶される各種網羅表を示す図である。ある製品系統に対応する不具合（故障）部位網羅表の一例を示す図である。ある製品系統に対応する不具合（故障）モード網羅表（ヒューマンエラーベース）の一例を示す図である。ある製品系統に対応する不具合（故障）モード網羅表（物理現象ベース）の一例を示す図である。ある製品系統に対応する不具合（故障）現象網羅表（ヒューマンエラーベース）の一例を示す図である。ある製品系統に対応する不具合（故障）現象網羅表（物理現象ベース）の一例を示す図である。ある製品系統に対応する不具合（故障）結果網羅表の一例を示す図である。ある製品系統に対応する不具合（故障）原因網羅表（ヒューマンエラーベース）の一例を示す図である。ある製品系統に対応する不具合（故障）原因網羅表（物理現象ベース）の一例を示す図である。ある製品系統に対応する不具合（故障）対策網羅表（ヒューマンエラーベース）の一例を示す図である。ある製品系統に対応する不具合（故障）対策網羅表（物理現象ベース）の一例を示す図である。図３のＰＰＭＤＢをベースに生成されたＱＡ２−ＫＤＢ２４上にハザードを設定した一例を示す図である。図３のＰＰＭＤＢ２２をベースにして、ＱＡ２−ＫＤＢ２４の骨組みを生成する処理を示すフローチャートである。プロダクトモデル対応のデータ構造の一例を示す図である。プロダクト・プロセスモデル対応のデータ構造の一例を示す図である。生成された図３のＱＡ２−ＫＤＢ２４の骨組みに対し、ロジックを追加したところを示す図である。図３の登録部１０の機能の一例を説明する図である。図３の不具合対策支援部４０が行う全体的な処理の流れを、簡単なフローと共に説明する図である。不具合原因追求支援機能を説明する図である。不具合（故障）原因追求（支援）機能をより具体的に説明する図である。不具合（故障）の原因追求（支援）処理のフローチャート（その１）である。不具合（故障）の原因追求（支援）処理のフローチャート（その２）である。（対象不具合の）原因追求支援処理において原因（要因）候補リストが出力される様子を説明する図である。導板と台金を部品として構成されるユニットに対応するＱＡ２−ＫＤＢの構築例を示す図である。図３１のユニット１を構成する部品１−１（導板）の実体／状態データモデルを、その部品１−１に適用されるＳＳＭメソッド（ロジック）と共に示した図である。図３１のユニット１を構成する部品１−１（導板）の実体／状態データモデルを、その部品１−１に適用されるＦＴＡメソッド（ロジック）と共に示した図である。発生確率（寄与率）を算出する対象としての故障木の一例を示す図である。図３４の故障木に対応するテーブルであり、構造重要度を算出する際に用いるテーブルである。原因追求支援処理における原因（要因）候補リストの出力例を示す図である。不具合（故障）影響分析機能を具体的に説明する図である。不具合（故障）影響分析処理のフローチャートである。不具合未然防止支援処理のフローチャートである。ある対象製品系統に適用されるＦＭＥＡメソッド（ロジック）を示す図である。対策候補リストのメンテナンス機能を説明する図である。各種不具合対策支援処理の結果として出力される候補リストを示す図である。実体／状態データモデルの一例を示す図である。図４３の実体／状態データモデルの記述に利用される不具合原因網羅表を示す図である。図４３の実体／状態データモデルの記述に利用される不具合部位網羅表を示す図である。本実施形態における、各種データの実在の仕方を示す図である。

符号の説明

１０登録部
２０知見・ノウハウ蓄積部
２１不具合網羅表記憶部
２１ａ不具合部位網羅表
２１ｂ不具合モード網羅表
２１ｃ不具合現象網羅表
２１ｄ不具合結果網羅表
２１ｅ不具合原因網羅表
２１ｆ不具合対策網羅表
２２ＰＰＭＤＢ
２３知識データ記憶部
２４ＱＡ２−ＫＤＢ
３０参照部
４０不具合対策支援部

Claims

１以上の実体から生産される製品に関わる生産システムに生じる不具合に対する対策を支援する装置において、
前記実体で発生しうる不具合現象の網羅的な集合を示す情報を記憶する第１の不具合網羅記憶手段と、
前記第１の不具合網羅記憶手段に記憶されている不具合現象を形態別に整理して得られる不具合モードの網羅的な集合を示す情報を記憶する第２の不具合網羅記憶手段と、
製品構造情報と製造工程情報とを互いに関連付けて表現したモデル情報を製品・工程モデルとして記憶する製品・工程モデル記憶手段と、
仕様書や標準書のデータ、製造方法に関する知識や生産システムにおける知見・ノウハウに関する知識等からなる知識データを記憶する知識データ記憶手段と、
をあらかじめ備え、
前記第１及び第２の不具合網羅記憶手段に記憶されている前記網羅的な集合を示す不具合現象、不具合モード、及び、前記知識データ記憶手段に記憶されている知見・ノウハウ等の各種データをユーザが読み出して且つ該データを参照し、更に前記製品・工程モデル記憶手段に記憶された前記モデル情報を読み出して該モデル情報を骨組みとして持ち、該骨組みに対してユーザが該モデル情報に展開されている各属性に対して対応する属性値を記述するとともに既存の各種方式を用いて判定を行うロジック、並びに前記製品・工程モデル記憶手段に記憶された前記製造工程情報の属性としての状態情報、状態遷移の方向に係る情報を付加して品質知識データベースを構築する手段と、
所定の不具合現象が発生した際に、構築された前記品質知識データベースを読み出して、前記モデル情報中に存在する実体に複数の属性データを関連付ける手段および前記関連付けられた属性データの少なくとも一部を用いて前記実体における不具合現象の発生確率を算出して不具合の原因追求・影響分析による対策支援を行う第１の不具合対策支援手段と、
所定の不具合が起こる前に、構築された前記品質知識データベースを読み出して、前記モデル情報中に存在する実体に複数の属性データを関連付ける手段および前記関連付けられた属性データの少なくとも一部を用いて前記実体を用いる製品に内在する危険因子を危険優先度として算出し、該危険優先度を不具合未然防止支援に用いる第２の不具合対策支援手段と、
前記第１の不具合対策支援手段の前記不具合の原因追求による対策支援に対しては要因候補リストを、また前記不具合の影響分析による対策支援に対しては影響範囲と影響度候補リストを、それぞれ確率（寄与率）順にソートして出力し、一方、前記第２の不具合対策支援手段の前記不具合の未然防止支援による対策支援に対しては対策候補リストを確率（寄与率）順にソートして出力する出力手段と、
を備えることを特徴とする生産システムにおける不具合対策支援装置。
前記既存の方式はＦＴＡ方式であり、
前記第１の不具合対策支援手段は、
所定の不具合現象が発生した実体について、該所定の不具合現象に対応付けられた前記不具合モードが論理ゲートを介してツリー構造の各部に配置されてなるＦＴＡ情報を記憶する手段と、
前記ＦＴＡ情報のツリー構造を、前記所定の不具合現象が発生した実体を分析の開始点として該分析の開始点から所定の向きに進むことによって、該ツリーの各部に位置する不具合モードの発生確率（寄与率）を前記ＦＴＡ方式に基づいて算出する手段と、を備えることを特徴とする請求項１記載の不具合対策支援装置。
前記ＦＴＡ情報に基づいて、前記既存のＦＴＡ方式が該事象の発生確率（寄与率）を算出する場合に、
互いに排反事象とは限らない、複数の原因事象の論理和から結果事象が導かれる構造を前記ツリー構造が示す場合に、前記結果事象の発生確率を前記複数の原因事象の発生確率で表した式における、該複数の原因事象の発生確率の２つ以上の積により構成される項を、該複数の原因事象の発生確率の２つ以上に所定の割合で分配するようにして、該原因事象の結果事象に対する寄与率を算出する手段を有することを特徴とする請求項２記載の不具合対策支援装置。
前記分析の開始点は不具合現象が発生した実体であり、該実体は他の実体との間にインターフェイスを介して相互作用を有することを特徴とする請求項２記載の不具合対策支援装置。
前記インターフェイスを介して前記実体に影響を与える他の実体と、前記実体に対応する製造工程とでは、前記実体に発生した所定の不具合現象への発生原因としての寄与分が、いずれが大きいかを算出する手段を更に有し、
該原因寄与分算出手段によって、前記実体に対応する製造工程からの影響の方が大きいと算出された場合には、前記発生確率（寄与率）算出手段は、前記実体に対応する製造工程の前記ＦＴＡ情報に基づいて、前記実体に対応する製造工程に対して発生確率（寄与率）の算出を行うことを特徴とする請求項４記載の不具合対策支援装置。
前記インターフェイスを介して前記実体が影響を及ぼす他の実体と、前記実体が組み込まれる組立工程とでは、前記実体に発生した所定の不具合現象への影響としての寄与分が、いずれが大きいかを算出する手段を更に有し、
該影響寄与分算出手段によって、前記他の実体への影響の方が大きいと算出された場合には、前記発生確率（寄与率）算出手段は、前記他の実体に対応する前記ＦＴＡ情報に基づいて、前記他の実体に対して発生確率（寄与率）の算出を行うことを特徴とする請求項４記載の不具合対策支援装置。
前記既存の方式はＦＭＥＡ方式であり、
前記第２の不具合対策支援手段は、
前記製品を構成する任意の実体について、該実体に対応付けられた前記不具合モードの危険優先度を前記ＦＭＥＡ方式に基づいて算出することを特徴とする請求項１記載の不具合対策支援装置。