JP2007241774A - 知見・ノウハウの体系化支援装置、その方法、プログラム - Google Patents

Abstract

【課題】知見・ノウハウの関係をプロダクト／プロセス各々の構造ベースの情報表現モデルを統合したモデルを用いて整理・記述する。
【解決手段】製品・工程モデルＤＢ２２は、製品構造情報モデルと工程構成情報モデルを統合化した統合モデルを格納している。この統合モデルをベースとして、製品の設計モデルの不具合のモデル化に加え、生準・製造における不具合もモデル化する。そして、この統合モデルは工程を状態遷移により表現しているため、生産システムにおける不具合の因果連鎖関係に基づく不具合発生メカニズムも表現することができる。品質知識ＤＢ２３は、上記統合モデルに基づく、実体（ユニット/部品）と状態（工程）のそれぞれを属性とメソッドにより表現した実体/状態データモデルを格納し、生産システムにおける知見・ノウハウを体系的に記述可能としている。
【選択図】 図１

Description

本発明は、生産システムにおける知見・ノウハウの蓄積・体系化の支援システムに関する。

従来より、生産システム、特に加工組立型生産システムにおいて、生産時に発生する問題を設計、生産準備（生準）・生産技術段階で早期発見し、早期対応することにより、生産時に発生する問題を最少化することが望まれている。また、ロスコストの改善、市場投入遅れの改善、市場投入後の不具合による製品ブランドイメージダウンの改善が求められている。問題発生の主要因としては、例えば
・設計時に製造現場との調整ができていない
・設計時に問題の洗い出しが十分でない。
・設計時の工程能力が実態とあっていない。
・試作時に量産時の課題・問題が十分に検討されていない
等が挙げられる。

これらの問題を解決する為に、生産システムにおける知見・ノウハウのトータルマネージメント技術及び支援システムが要求される。しかし、既存の技術及び支援システムでは前者を統合的に支援する環境は整備されていないし、また、生産システムの品質管理においても、ほとんどのシステムでは部分的な機能しか行なわれていない。

生産システムにおける知見・ノウハウのトータルマネージメントに関しては、まず、例えば、現状の生産システムのプロセスでは、大別して、設計段階と製造段階とがあり、設計段階は更に企画・設計段階と試作・工程設計段階とに分けられ、製造段階は更に据付・調整段階、生産準備段階、量産製造段階に分けられる。また、通常、設計においては設計ノウハウ、製造においては工場生産ノウハウ、不具合改善ノウハウ等の知見・ノウハウを有している。上記問題を解決する為に、不具合改善ノウハウ等の蓄積と設計段階へのフィードバック、更に設計・試作・工場生産ノウハウの蓄積と再利用の促進というアプローチが考えられる。

ここで、図２６に、設計、生産準備、量産製造における情報の流れを示す。
同図において、製品設計段階では、データベース４０１に蓄積された市場情報、商品企画情報等に基づいて、任意の製品の機能、部品構成、形状、材質、信頼性等の設計を行う。そして、設計結果をデータベース４０２に格納する。図示の例では例えば製品図面、材質、製品モデルデータ、Ｅ−ＢＯＭ、設計ＦＭＥＡ（設計工程信頼性設計）等が格納される。

ここで、Ｅ−ＢＯＭのＢＯＭ（Bill of Material）とは、部品表のことをいい、部品表とは１つの製品を構成する部品のリストを一覧表として提示したものである。Ｅ−ＢＯＭ（エンジニアリングＢＯＭ）とは、設計に用いられるＢＯＭのことで、製品がどのような部品によって構成されているかを示していて、個々の部品の機能や仕様や形状が詳しく記述されている。尚、ＢＯＭには、他にも後述するＭ−ＢＯＭ（マニュファクチュリングＢＯＭ）があり、これは、Ｅ−ＢＯＭの情報を製品計画やスケジューリング等、実際の生産活動の中で利用可能にするために製造の仕方等の知識が記述されているものである。

再び図２６において、続いて生産準備段階では、データベース４０２に格納された設計結果情報と、予めデータベース４０３に格納されている各種情報、すなわち設備能力（Ｃ／Ｔ）、工程能力（Ｃ／Ｔ）、作業性（点検、工具交換）、治工具能力、設備・治工具コスト、各種制約条件等の情報に基づいて、工程／設備／治・工具設計を行う。当該工程／設備／治・工具設計とは、製造構成・フロー設計、Ｍ−ＢＯＭ作成、設備・治工具選択、レイアウト設計、工作図（加工部位・基準・寸法・方法、ツールパス）作成、製造工程信頼性設計（工程ＦＭＥＡ）等である。この結果はデータベース４０４に格納される。

図示の例では、データベース４０４には、設備／治・工具仕様書、設備／治・工具配置図、工作図、レイアウト図、プログラム／パラメータ、製造条件／工程フロー／作業要領/品保基準、Ｍ−ＢＯＭ、工程ＦＭＥＡ等が格納される。

そして、量産製造段階では、データベース４０４に格納された情報を用いて、製品製造を行う。
生産準備段階、量産製造段階で不具合が発生した場合には、その上流段階（設計または生産準備）にフィードバックする。また、製品を市場に投入後、市場において不具合が発生した場合には、市場での不具合情報（不具合箇所やその現象（例えば異常振動等））を、設計／生産現場へとフィードバックする。

図２７に、このような不具合対応処理の業務フローを示す。すなわち、不具合再発防止業務の業務フローを示す。
生産準備段階／量産製造段階での不具合、または市場での不具合は、不具合連絡票という形でフィードバックされる。

不具合対応処理の業務部門などでは、この不具合連絡票に基づいて、まず、現象確認を行う。これは、例えば、
・一次原因の特定
・重要性の決定（すぐ対応か、後回しかを決定）
・優先順位を決定
・発生頻度の確認
・送り先の決定
等である。

次に、上記現象確認での決定事項に応じた処置を行い、続いて、原因追究（真因を調べる）を行う。更に、影響分析を行う。これは、影響する部品と工程の範囲を調べ、影響程度を把握し、送り先を決定する。

そして、対策検討を行う。これは、代替案の立案（一次対策、恒久対策）、効果の見積り、実行順番の決定等である。
以上の業務を実行したら、対策の実施を行う。これは、代替案の中から実行する案を選択し、実施決定し、実行部署に通知する。もし、実行部署が製品設計段階の部署であれば仕様見直し等を行い、工程設計であれば標準・基準、作業手順、加工法の見直し等を行い、設備設計であれば設備・工具仕様、作業環境、レイアウトの見直し等を行い、量産製造であればポカヨケ対策の見直し等を行う。

そして、実行部署は、実施した旨、及び実施した結果をフィードバックする（実施確認）。これを受けて、処理結果、再発防止対策をクレーム発行部門に報告する（品調回答）。

ここで、上述した不具合再発防止業務に関して、以下に示す２つの問題点があった。
１．事前検討時において、製品設計、生産技術、製造での検討が、不十分／漏れる／遅れる。
２．仕様書、基準書・標準書の見直しが、遅れる／漏れる。

上記のような問題が生じる原因として、以下の問題点が考えられる。
（１）知見ノウハウの量と質の問題
・不具合に関して蓄積した知見・ノウハウが不足している。

・不具合に関して蓄積した知見・ノウハウが多すぎて、有用な情報を取り出せない。
・情報の表現、記述には個人差が大きい為、活用し難い。
（２）知見ノウハウの活用の問題
・真因追究／影響範囲の把握が難しい。

・過去の対策事例が活用されていない。
・仕様書、基準書・標準書の見直しが、タイムリーにされていない。
・知見・ノウハウの利用はされているが、対策が実施されているか否かのチェックはされていない。
（３）共有の問題
・他工場、他ラインの類似不具合が共有されていない。

・経験者であれば、類似不具合が他のどこで発生するかが分かるが、未経験者には難しい。
ここでは、（１）知見ノウハウの量と質の問題に対応することを考える。

この問題を解決する為に、以下の仕組みを実現することが望まれる。
・知見・ノウハウの登録を容易にする仕組み。
・知見・ノウハウの表現・記述の個人差を無くす仕組み。
・大量の知見・ノウハウから必要なものを容易に取り出す仕組み。

ここで、例えば、特許文献１記載の発明においては、従来より、各部門（設計部門、製作部門）の知識やデータを一元管理し、他の部門に公開するデータベース化が実施され、他の部門のデータを自部門の業務の品質向上に生かすシステムが望まれていることに対して、製品に関する情報である製品情報を記録する製品データベースと、製品から形成されるプラントに発生するトラブルの内容とトラブルが発生した後に検査するべき複数の検査方法とを対応付けて記録するトラブルデータベースとを有し、上記製品情報に基づいて、どの製品がそのトラブルを引き起こしているかを推測し、その製品から順番に検査するように検査手順を作成する。その際、設計値と実測値との差があるとトラブルを発生させることが一般的に多いと考えている。

上記の従来技術では、各部門（設計部門、製作部門）の知識やデータを一元管理する発想まではあるが、上記（１）知見ノウハウの量と質の問題に対応するのに十分な仕組みまで考えられていない。

次に、不具合の防止に関する既存手法について説明する。
まず、田村などによる「設計トラブル未然防止手法ＳＳＭ（ストレス強度モデル：Stress Strength Model）」について説明する。この手法は、製造業における不具合の未然防止設計を対象分野とするもので、不具合の因果連鎖のメカニズムを従来のＳＳＭを一般化したモデルを単位とした連結構造で表す。そして、ＳＳＭ形式で蓄積した汎用的な不具合知識の中から、不具合概念間の階層関係などを用いて設計仕様に合致する知識を設計段階で抽出し、その知識を設計トラブルの未然防止に活用するものである (例えば、非特許文献１、２，３参照)。

また、ＦＴＡは、システムにおける不具合事象の原因分析（人的要因、ソフトウェアによる要因も含む）を対象分野としており、不具合現象（事象）をトップ事象とし、その不具合原因となる中間事象を論理ゲートを介してトップダウン的に順次辿り、全ての原因事象まで展開した故障木を用いて信頼性を図式的に分析するものである。この分析手法では、故障木を用いて、トップ事象の発生経路、致命的事象を定めることにより、関連部の信頼性弱点の指摘と対応策の勧告ができ、故障木の図式表示によって、システムの弱点が何であり、それがどのようにして不具合につながるかを明確に理解できる。

しかし、事象が正常/異常のいずれかの状態にあることを前提としており、中間的、過渡的な状態にある場合は解析できない。また、トップ事象に無関係な中間・原因事象は解析できない（例えば、非特許文献４参照）。

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

しかしながら、複合要因の不具合（故障）についてブール代数を用いて論理的解析ができない（単一故障の影響解析に適する）（非特許文献４参照）。
失敗まんだら（科学技術振興事業団の畑村の統括による失敗知識データベースで採用）は、人がかかわる全ての失敗事例とヒューマンエラーを中心とする失敗の概略分析を対象分野とし、全ての失敗事例はヒューマンエラーであるという認識に立ち、失敗の脈絡を、人的原因→人の行動→結果という流れとして構造化する。そして、「原因」、「行動」、「結果」のそれぞれのフェーズをまんだらとして、さらに、それらのまんだらを階層分類し、体系化・標準化するところが大きな特徴で、これにより失敗を知識化する。この技法では、原因、行動、結果のパターンやキーワードを用いて類似事例を検索し、教訓を得ることができる。

しかし、失敗の因果の概略を表現できるが、その因果メカニズムを精緻に表現することができない。また、各失敗の事例を組み合わせて、新たに想定される失敗事例を予測することはできない。この技法では、原因、行動、結果の各まんだらで定義された階層分類を用いて失敗事例を体系化しているので、不具合（特に、人的要因による不具合）の体系化・標準化を実現している（非特許文献５参照）。

段階的信頼性設計支援システム（古賀-青山モデル）は、段階的設計（トップダウン設計）における信頼性評価を対象分野とするもので、製品モデルを「実体」、「属性」、「インタフェース」の３要素により表現し、段階的詳細化を特徴とするトップダウン設計の各段階において、製品モデル情報と製品利用時に想定されるハザード情報から、発生しえる故障群を設計モデルの各段階に対応した階層を持つ別途作成した階層的故障データベース（階層的故障ＤＢ）により抽出・利用することで、ＦＭＥＡ、ＦＴＡ等の信頼性評価を支援する。階層的故障ＤＢには、過去の故障事例を広く集め、ＳＳＭに潜在的危険源であるハザードの表現と実体間のインタフェースを介したストレスの伝播メカニズムの表現を追加した故障ユニットに変換した形で蓄積しておく。

この技法では、設計の各段階で、設計モデルに想定される故障群を抽出可能であり、それらを用いて、ＦＭＥＡでは故障モードと及ぼす影響のリストを、ＦＴＡではトップ事象の展開の一次案を設計者に提供することで、信頼性評価において過去事例という観点から網羅性を検討できる。また、設計の上流段階から逐次的に信頼性の改善ができる。

しかし、製品モデルはＥ−ＢＯＭをベースに構成するが、Ｍ−ＢＯＭとは無関係であるため、生技・製造情報に起因する不具合を解析することができない（非特許文献６，７参照）。

ここで、Ｍ−ＢＯＭ，Ｅ−ＢＯＭについて説明する。まず、ＢＯＭ(Bill of Material)とは、部品表のことである。部品表とは、１つの製品を構成する部品のリストを一覧表として掲示したものであり、企画、設計、製造、販売などの様々な部門で使用されている。

部品表には、サマリー型とストラクチャ型がある。サマリー型部品表は、最終製品１個当たりに必要な部品名と数量のみを最終製品に対応する形で表示したもので、部品展開に用いられる。サマリー型部品表は、購買担当以外にはあまり役立たない。

ストラクチャ型部品表は、素材から製品にいたるまでの各部品の相互の構成関係を表示したもので、どの親部品がどの子部品から構成されるかが一目瞭然でわかる。ストラクチャ型部品表は、設計部門、製造部門でも利用できる。

Ｅ−ＢＯＭは、設計に用いられるＢＯＭのことでエンジニアリング(Engineering)ＢＯＭといわれ、製品がどのような部品によって構成されているかを示していて、個々の部品の機能や仕様や形状が詳しく記述されている。Ｍ−ＢＯＭは、製造に用いられるＢＯＭのことで、マニュファクチャリング(Manufacturing)ＢＯＭといい、Ｅ−ＢＯＭの情報を製造計画やスケジューリングなど、実際の生産活動の中で利用可能にするために製造の仕方などの知識が記述されている。
特開２００３−４４５４６号公報 田村泰彦、他２名、"不具合に関する構造化知識の活用システムの開発" 斎藤秀夫、他５名、"不具合に関する構造化知識の運用の実践" 田村泰彦、"構造化本質知の運用による設計トラブル未然防止システムの実践"、Justsystem Knowledge Management Forum 2003, 鈴木順二郎他著 「ＦＭＥＡ・ＦＴＡ実施法」日本科技連、１９８２年出版 統括 畑村洋太郎、"失敗知識データベースの構造と表現」（「失敗まんだら」解説）"、平成１４年１２月、科学技術振興事業団 失敗知識データベース整備事業 古賀毅,他２名,"信頼性設計を段階的に支援する故障情報マネージメントシステムの提案と構築",２００１年１２月６日,日本機械学会 第１０回 交通・物流部門大会 ＴＲＡＮＳＬＯＧ ２００１ 古賀毅,他３名,"トップダウン指向情報モデルにおける製品の信頼性マネジメントシステムの構築", ２００２年１１月２９日、日本機械学会 第１２回 設計工学・システム部門講演会

本発明の課題は、生産システムにおける知見・ノウハウについて、その獲得過程を事象の網羅表を用いて支援し、知見・ノウハウの関係をプロダクト構造ベースの情報表現モデルとプロセス構造ベースでの情報表現モデルを統合したプロダクト・プロセスモデルを用いて整理・記述することにより知見・ノウハウを体系化する方法、装置、プログラム等を提供することである。

本発明による知見・ノウハウの体系化支援装置は、プロダクト構造ベースでの情報表現モデルとプロセス構造ベースでの情報表現モデルを統合した統合モデルをデータベース化して格納する統合モデル格納手段と、前記統合モデルに基づいて、該統合モデルによって示される各実体、状態の各々について予め用意されている、少なくとも各実体または状態に関連する各種対象事象を属性として定義したテンプレートを用いて、実体/状態データモデルの骨組みを作成する実体/状態データモデル作成手段と、前記実体/状態データモデルの骨組みに基づいて、前記各属性に対応する属性値、該属性値を用いた各種判定を行うメソッド、ハザード伝播を記述してなるデータモデルを作成させて格納する知見・ノウハウ体系化／蓄積手段とを有するように構成する。

上記従来の段階的信頼性設計支援システム（古賀-青山モデル）では、上述してあるように、製品モデルはＥ−ＢＯＭをベースに構成するが、Ｍ−ＢＯＭとは無関係であるため、生技・製造情報に起因する不具合を解析することができない。

これに対して、上記本発明による知見・ノウハウの体系化支援装置では、プロダクト構造ベース（Ｅ−ＢＯＭベース）での情報表現モデルとプロセス構造ベース（Ｍ−ＢＯＭベース）での情報表現モデルを統合した統合モデルを格納しているので、このような問題を解消できる。更に、この統合モデルに基づいて上記知見・ノウハウ体系化／蓄積手段に格納するデータモデルを作成・蓄積することができる。つまり、生産システムにおける設計から製造プロセスまでの全てについての知見・ノウハウを体系的に記述・蓄積することができる。これによって例えば、不具合改善ノウハウ等の蓄積・共有化が容易になる。

更に、実体/状態データモデルの骨組みは自動作成されるので、人手による作成の手間が軽減される。
また、上記データモデルでは、前記各実体の機能を設計する過程から製造する過程までの全ての知見・ノウハウを、前記実体/状態データモデルにおける各属性の属性値として格納することになる。

また、知見・ノウハウの体系化支援装置において、例えば更に、上記予め前記各種対象事象を階層的に網羅的に整理してその属性値を記述した各種網羅表を格納する網羅表格納手段と、前記各種網羅表に基いたマスタテーブルを表示して任意の属性値を選択させることで、前記実体/状態データモデルにおける任意の属性に対応する属性値を登録させるデータ登録支援手段とを有するように構成してもよい。

各種対象事象を階層的に、網羅的に整理し、データ取り入れのためのマスタテーブルとして利用することにより、事象間に階層関係を持つことができると同時に、事象の記述を人に属せずに共通的に表現できる。そして、実体/状態データモデルの属性値の登録に利用することにより、知見・ノウハウの表現・記述の個人差を無くすことができ、知見・ノウハウの登録を容易にすることができる。

本発明の知見・ノウハウ体系化支援装置、その方法、プログラム等によれば、プロダクト構造ベースの情報表現モデルとプロセス構造ベースでの情報表現モデルを統合した統合モデルを用いて整理・記述することができ、更にこれに基づいて生産システムにおける設計から製造プロセスまでの全てについての知見・ノウハウを体系的に記述・蓄積（実体／状態データモデル）することができる。また、この実体／状態データモデルの骨組みは上記統合モデルに基づいて自動で作成することができる。更に属性、属性値の記述を事象の網羅表を用いて支援することができ、これによって知見・ノウハウの登録を容易にする仕組み、知見・ノウハウの表現・記述の個人差を無くす仕組み、大量の知見・ノウハウから必要なものを容易に取り出す仕組みを提供できる。

以下、図面を参照して本発明の実施の形態について説明する。
図１は、本例による知見・ノウハウの体系化装置１０の機能ブロック図である。
本例による知見・ノウハウの体系化装置１０は、体系化・蓄積機能部１１、登録機能部１２、参照機能部１３より成り、体系化・蓄積機能部１１に蓄積されるデータは、網羅表ＤＢ（データベース）２１、製品・工程モデルＤＢ（データベース）（ＰＰＭＤＢ）２２、品質知識ＤＢ（データベース）（ＱＡ２−ＫＤＢ）２３、及び知識データＤＢ（データベース）２４の各データベースに格納される。

尚、ＰＰＭＤＢは、Product and Process Model Data Base、ＱＡ２−ＫＤＢは、Quality Analysis / Question Answering Knowledge Data Baseの略である。
体系化・蓄積機能部１１は、特に図示しないが、プロダクト構造ベースでの情報表現モデルとプロセス構造ベースでの情報表現モデルを統合した統合モデルをデータベース化して製品・工程モデルＤＢ（データベース）（ＰＰＭＤＢ）２２に格納する統合モデル格納機能部と、この統合モデルに基づいて、該統合モデルによって示される各実体、状態の各々について予め用意されている、少なくとも各実体または状態に関連する各種対象事象を属性として定義したテンプレートを用いて、実体/状態データモデルの骨組みを作成する実体/状態データモデル作成機能部とを有し、この実体/状態データモデルの骨組みに基づいて、各属性に対応する属性値、該属性値を用いた各種判定を行うメソッド、ハザード伝播を記述してなるデータモデルを作成させて、品質知識ＤＢ（データベース）（ＱＡ２−ＫＤＢ）２３に格納する。尚、属性、属性値については後述する。

登録機能部１２は、事前検討した設計情報に基づく網羅表を用いて、知識データＤＢ２４および品質知識ＤＢ２３への属性値等の登録作業を行わせる。これによって、属性値の記述内容が標準化され、上記従来の「情報の表現、記述には個人差が大きい為、活用し難い」という問題が解消される。また、階層的に整理された網羅表から属性値等を選択することで登録できるので、登録作業の手間が軽減できる。

製品・工程モデルＤＢ（ＰＰＭＤＢ）２２は、プロダクト構造ベース（Ｅ−ＢＯＭ）での情報表現モデルである製品構造情報モデルと、プロセス構造ベース（Ｍ−ＢＯＭ）での情報表現モデルである工程構成情報モデルを統合化した統合モデル（プロダクト-プロセスモデル(PPM)）を格納しているデータベースである。この統合モデルは、製品の設計モデルのモデル化に加え、生準・製造における各状態、状態遷移もモデル化したものである。そして、この統合モデルは工程を状態遷移により表現しているため、生産システムにおける不具合の因果連鎖関係に基づく不具合発生メカニズムも表現できる。

知識データＤＢ２４は、設計仕様、標準・基準書、製造方法に関する知識や生産システムにおける知見・ノウハウに関する知識ファイル（生データ）を格納している。
品質知識ＤＢ（ＱＡ２−ＫＤＢ）２３は、上記統合モデルによって表現される実体（ユニット/部品）とその構成関係、及び状態／状態遷移（工程）に基づいて作成され、更に知見・ノウハウを利用した属性とメソッド、ハザードの伝播、相互作用（インタフェースを介して、実体が他の実体にストレスを加えること）等を記述した複数の実体/状態データモデルを格納するオブジェクト指向の知識データベースである。また、詳しくは後述するが、品質知識ＤＢ（ＱＡ２−ＫＤＢ）に格納される各実体／状態データモデルの基礎（骨組み）と当該各モデル間の構成関係は、製品・工程モデルＤＢ（ＰＰＭＤＢ）２２に格納されている統合モデル情報を基に自動作成される。そして、自動作成された骨組みに基づいて、人手によって、属性の追加、変更、網羅表に基づく属性値の入力、任意の属性値の入力、メソッドの選択・設定もしくは新規作成、ハザードとハザードの伝播、相互作用の記述等を行って、上記オブジェクト指向の知識データベースを完成させる。

網羅表ＤＢ２１には、不具合に係わる部位、現象、結果、原因等が、属性、属性値として体系化された各種網羅表が格納されており、上記網羅表に基づく属性値の入力の際に利用される。網羅表は、各種対象事象を階層的に網羅的に整理したテーブルである。

また、参照機能部１３によって、各部署（製品設計、工程設計、設備設計、量産製造）から、体系化・蓄積機能部１１に蓄積されるデータを参照することができ、それぞれの業務に役立てることができる。

図２に、本例による知見・ノウハウの体系化装置と、これに係わるシステム全体の処理フローを示す。
同図において、知見・ノウハウの体系化装置１０については、図１で説明した通りである。図２に示すように、これら知見・ノウハウの体系化装置１０に格納されたデータを用いて、現象確認、優先度判定支援、原因追究支援、影響分析支援、対策案検討施策決定、実施部署通知等の機能が実現されるが、本例の装置の特徴自体ではないので、ここでは特に説明しない。

本例の装置１０の特徴は、知見・ノウハウの体系化装置１０自体に係わるものであり、図３に示すように、（１）工程を状態遷移により表現できる、（２）知見・ノウハウを体系化できる、（３）知見・ノウハウを蓄積・進化できる、ことを特徴としている。更に、知見・ノウハウの体系化に際して、その属性値等の記述を、網羅表を用いて標準化、容易化できることを特徴としている。

図３において、知見・ノウハウの体系化装置１０は、各種既存技法、すなわち失敗まんだら、ＳＳＭ(Stress-Strength Model；ストレス−強度モデル)、ＦＴＡ(Fault Tree Analysis)、ＦＭＥＡ(Failure Model and Effects Analysis)、古賀−青山モデルを、一部利用して、各種データベースの構築を行っている。その際、Ｍ−ＢＯＭ（生技・製造情報）を知識データＤＢ２４等から取り込んで、データベース構築に利用する（図示していないが、Ｅ−ＢＯＭも当然に利用する）。

まず、失敗まんだらの考え方に基づいて、人が、故障モード、現象、原因、結果、施策等を網羅的に整理して、上記網羅表を作成し、網羅表ＤＢ２１に格納する。
また、不具合因果メカニズムの汎用的表現を、ＳＳＭと古賀−青山モデルに基づいて実現する。これは、ＳＳＭにより不具合発生の因果関係を表現する。すなわち、不具合の因果連鎖のメカニズムを、従来のＳＳＭを一般化したモデルを単位とした連結構造で表す。ＳＳＭ形式で蓄積した汎用的な不具合知識の中から不具合概念間の階層関係等を用いて設計仕様に合致する知識を設計段階で抽出する。これにより、製品に発生し得る不具合知識の製品設計時における抽出を可能にし、またＦＭＥＡ、ＦＴＡの実施を支援する。

また、古賀−青山モデルでは、まず、不具合を発生し得る危険源を抽象化したものをハザードとして表現する。また、製品構造情報（Ｅ−ＢＯＭ）を実体、属性、インタフェースの３要素で表現する。そして、ハザードは負荷として実体に作用し、ＳＳＭにより故障モード発生を表現し、故障の発生により製品状態が変化し、新たな危険源が発生すると考える。それが、更にインタフェースを介して他の実体に作用し（ハザードの伝播の表現）、他の実体で新たなハザードを引き起こすと考える。

また、ＦＴＡに基づいて、複数の事象のつながりを論理ゲートで表現でき、複合原因による故障も論理ゲートを用いて扱える。更に、樹形図の確率的記述より、結果事象（トップ事象）を引き起こす原因事象の貢献度の確率的分析ができる。

また、ＦＭＥＡに基づいて、対象事象の危険優先度を、発生頻度・影響度・検出難易度に基づいてランク付けることができる。
そして、上記網羅表ＤＢ２１に格納される網羅表、及び品質知識ＤＢ２３に格納される実体／状態データモデルの属性により、知見・ノウハウを体系化できる。また、品質知識ＤＢ２３に格納される実体／状態データモデルの属性・属性値の追加・更新により、知見・ノウハウを蓄積・進化することができる。

ここで、上記既存手法を一部利用することについて 以下、更に詳細に説明する。ここでは、上記従来の問題を解決するために、「不具合因果メカニズムの汎用的表現」、「多重故障の分析」、「不具合の体系化（人的要因も含む）・標準化」、「危険源（ハザード）の抽象化表現」、「製品構造情報を用いた不具合表現」及び「生技（生産技術）・製造情報を用いた不具合の表現」の各項目（評価項目）の機能を実現することを考える。

まず、上記各評価項目の概要を説明する。
「不具合因果メカニズムの汎用的表現」とは、下記の機能を実現するものである。
・ 対象の技術・技法が不具合に関する知見・ノウハウ情報を不具合因果メカニズムを抽象化した汎用的表現でモデル化できるかどうかを評価する。

・ 汎用的表現でモデル化して蓄積化した不具合に関する知見・ノウハウ情報を活用することにより、新たに発生した不具合の原因分析または影響分析を行う際に特定現象の原因を正しく遡及することができる。

・ このように、不具合因果メカニズムを抽象化／モデル化することにより類似した事象の検索が可能となり、自工程と類似した製品を製造する他工程または自工程と類似した製造方法が持つ他工程における知見・ノウハウを利用することが可能となる。

「多重故障の分析」とは、下記の機能を実現するものである。
・ 対象の技術・技法を用いて多重故障（複数の原因の複合によって発生する故障）の分析ができるかどうかを評価する。

・ 作業者が、原因分析・影響分析を行うとき、原因候補を漏れなく洗い出すために、原因から結果に至る因果関係を、不具合の原因が複数ある場合でも、蓄積された過去の知見・ノウハウ情報（現象と原因を含む）を論理的に正しく表現できる。

「不具合の体系化・標準化」とは、下記の機能を実現するものである。
・ 対象の技術・技法が不具合の体系的表現及び記述の標準化ができるかどうかを評価する。

・ 不具合現象を記述するとき、表現と記述方法を体系化・標準化しておくことにより、作業者の経験差や言葉の表現の違いがあっても、誰でも不具合現象を同等に記述できる。

・ 原因分析を行うために検索語を入力するときに、検索語を体系化・標準化しておくことにより、作業者の経験差や言葉の表現の違いがあっても、誰でも不具合原因の追求（検索）ができる。

「危険源（ハザード）の抽象化表現」とは、下記の機能を実現するものである。
・ 対象の技術・技法が危険源を抽象化表現できるかどうか評価する。
・ 作業者が原因分析・影響分析を行うとき、不具合のメカニズムを抽出するために、不具合を引き起こすと思われる事象を潜在的危険源であるハザードに帰着させる。ハザードは、負荷として実体に作用し、故障モードの発生メカニズムを明確化する。さらに、故障の発生による製品状態の変化で発生した新たなハザードがインターフェースを介して他の実体に作用することによって他の実体に新たなハザードを引き起こす。

というように、ハザードを介して不具合の伝播路をモデル化できる。
「製品構造情報を用いた不具合表現」は、下記のような機能を実現することができる。
・ 対象の技術・技法が製品構造情報を用いた不具合を表現できるかどうかを評価する。

・ 原因分析・影響分析・対象検討・知見ノウハウの蓄積を行うとき、不具合の原因が設計の欠陥（基準、標準、機能、材質、耐性、形状、寸法、精度、位置関係等）にある場合に、設計の業務プロセスにおける知見・ノウハウ（不具合情報を含む）を、製品構造情報に対応する機能情報に対応付けることにより、「××機能」で不具合が起きたとき、その原因が「××機能」を設計する業務プロセスにあることを特定できる「生技（生産技術）・製造情報を用いた不具合の表現」は、下記のような機能を実現できる。

・ 対象の技術・技法が生技・製造情報を用いた不具合を表現できるかどうかを評価する。
・ 原因分析・影響分析・対策検討・知見ノウハウの蓄積を行うとき、不具合の原因が生技の欠陥（基準、作業標準、チェック基準、製造方法、手順、条件、設備、治・工具、環境、レイアウト等）や製造の欠陥（ポカミス、不注意、基準に従わない等）にある場合に、生技・製造の業務プロセスにおける知見・ノウハウ（不具合情報を含む）を、工程情報に対応する生技・製造情報に対応つけることにより、不具合の原因が生技・製造の業務プロセスのどの部分にあるのか特定できる。

上記各機能を実現する為に上記各既存手法を応用することに関して、まず、上記田村などによる「設計トラブル未然防止手法ＳＳＭ（ストレス強度モデル：Stress Strength Model）」では、不具合発生の因果関係をＳＳＭにより表現するので、「不具合因果メカニズムの汎用的表現」が可能であり、製品に発生しえる不具合知識を製品設計時において抽出できる。また、ＦＭＥＡ，ＦＴＡ(Fault Tree Analysis) の実施を支援できる。但し、既存のＳＳＭの手法のみでは複数の不具合の伝播を表現することはできない。

また上記ＦＴＡの手法では、複合原因による故障も論理ゲートを用いて扱えるので、「多重故障の分析」が可能である。
また、上記段階的信頼性設計支援システム（古賀-青山モデル）では、ハザードは負荷として実体に作用し、ＳＳＭにより故障モード発生を表現し、故障の発生により製品状態が変化し、新たな危険源が発生すると考える。そして、それが、さらに、インタフェースを介して他の実体に作用し、他の実体で新たなハザードを引き起こすと考えるので、「不具合因果メカニズムの汎用的表現」が可能である。また、不具合を発生しうる危険源を抽象化したものをハザードとして表現するので、「危険源の抽象化表現」が可能である。さらに、製品構造情報（Ｅ−ＢＯＭ）を、実体、属性、インタフェースの３属性で表現し、製品構造情報を用いて、不具合の表現及び分析ができるので、「製品構造情報を用いた不具合の表現力」を実現することが可能である。

但し、上述してある通り、この既存手法では、製品モデルはＥ−ＢＯＭをベースに構成するが、Ｍ−ＢＯＭとは無関係であるため、生技・製造情報に起因する不具合を解析することができない。

これに対して、本例の手法では、プロダクト構造ベース（Ｅ−ＢＯＭ）での情報表現モデルとプロセス構造ベース（Ｍ−ＢＯＭ）での情報表現モデルを統合した統合モデルをデータベース化して格納するので、このような問題を解決できる。詳しくは後に説明する。

尚、上記各評価項目の機能を実現するために必要な要件を以下に列挙しておく。
「不具合因果果メカニズムの汎用的表現」の実現のために必要な要件は、「単一事象伝播メカニズムの汎用表現」と「発生メカニズムの汎用表現」である。「多重故障の分析」の実現のために必要な要件は、「多重現象関係の表現」である。「不具合の体系化・標準化」を実現するために必要な要件は、「体系化（分節性）」、「表現の平準さ」、「概念の体系化」及び「網羅性」である。「危険源の抽象化表現」の実現のために必要な要件は、「事業の抽象化」である。「製品構造情報を用いた不具合表現」の実現のために必要な要件は、「生技・製造情報の利用」である。

図４に、全体的な入出力のイメージを示す。
知見・ノウハウの体系化装置１０は、設計・生技・製造情報を統合管理し、知見・ノウハウを体系化、蓄積・進化するものであり、この知見・ノウハウの体系化装置１０の知見・ノウハウの蓄積等に用いる情報は、大別して、製品設計情報、工程設計情報、生産製造情報がある。

製品設計情報としては、構造・構成情報（Ｅ−ＢＯＭ）、図面、材質等仕様書のリンク情報、標準書・基準書のリンク情報、設計ＦＭＥＡ情報等がある。更に、人の頭脳にある知見・ノウハウとしての設計の知見・ノウハウ情報が、例えば任意の情報端末から人手によって入力される。

工程設計情報としては、データベースに格納されている工程の構成・順序（Ｍ−ＢＯＭ）、製造方法、製造条件等の各種情報と、作業要領／品保基準のリンク情報、設備／治・工具仕様書のリンク情報、設備／治・工具配置図のリンク情報、工作図、レイアウト図のリンク情報、工程ＦＭＥＡ情報等がある。更に、人の頭脳にある知見・ノウハウとしての工程設計知見・ノウハウ情報が、例えば任意の情報端末から人手によって入力される。

生産製造情報としては、人の頭脳にある知見・ノウハウである、製造知見・ノウハウ、ポカヨケ策、不具合原因、不具合対策等の情報が、例えば任意の情報端末から人手によって入力される。

本例の知見・ノウハウの体系化装置１０によれば、知見・ノウハウを体系的に蓄積・進化できる。また、必要な情報を簡単に閲覧・共有できる。更に、既存情報を利用して設計変更を行うときの利用すべき知見・ノウハウが、利用されているか否かを、後述するチェック対象（概念区分）とチェック要項を用いてチェックできる。

また、ここでは特に説明しないが、不具合の原因究明、不具合の影響把握、不具合の対策検討等にも利用できる。
上記網羅表ＤＢ２１に格納される網羅表について、図５〜図１１を参照して説明する。

網羅表は、基本的には、人間が手入力により定義・作成する。
網羅表の種類は、図５に示す例では、例えば故障部位網羅表３１、故障モード網羅表３２、故障現象網羅表３３、故障結果網羅表３４、故障原因網羅表３５、故障対策網羅表３６等がある。

故障部位網羅表３１と故障現象網羅表３３は、例えば製品・工程モデルＤＢ（データベース）（ＰＰＭＤＢ）２２の格納データに基づいて定義される。故障結果網羅表３４、故障原因網羅表３５、故障対策網羅表３６は、例えば失敗まんだらの考え方に基づいて定義される。

これら各種網羅表の具体例を図６〜図１１に示す。
尚、これらは、製品が自動車である場合を例にしている。
図６は、故障部位網羅表３１の具体例である。

図示の故障部位網羅表３１の例では、不具合に係わる部位（ここでは自動車を構成する各種部品）、例えばリム部、ハブ部、ステアリングメインシャフト部等が、階層的に分類・整理して記述されている。例えば、大分類として操舵装置、制動装置、駆動装置等に分類され、更に制動装置を例にすると中分類としてディスクブレーキ、ドラムブレーキ、ＡＢＳ装置に分類され、またディスクブレーキを例にすると小分類としてディスクローター、リテーナー、パッド、ピストン、キャリパーに分類されている。これら階層的な分類に従って上記不具合に係わる部位が記述されている。これらリム部、ハブ部、ステアリングメインシャフト部等の記述は、後述する図１５等に示すＱＡ２−ＫＤＢの実体／状態データモデル２００において、属性“部位”に対応する属性値を記述する際に利用される。また、これも後述するように、図１５等に示す実体／状態データモデル２００は、各部品／ユニット毎に存在するが、上記小部類は部品、中分類はこれら部品を組み合わせたユニット、大分類は更にこれらユニットを組み合わせた（上位の）ユニットに相当する。図１５等に示す実体／状態データモデル２００は、部品「ハンドル」に対応するものであり、それ故、その属性「部品」に対応する属性値は、図１５に示す通り、「リム部」、「ハブ部」、「スポーク部」等となっている。

以下に説明する他の網羅表は、上記故障部位網羅表３１のような複数の実体／状態データモデル２００間の構成に直接係わる分類ではないが、故障モード、現象、原因、結果、対策に係わる属性値等が、階層的に分類・整理されて記述されている。

図７は、故障モード網羅表３２の具体例である。
故障モードは、大別して、図７（ａ）に示すヒューマンエラーベースのものと、図７（ｂ）に示す物理現象ベースのものとに分類される。

図７（ａ）に示す例では、ヒューマンエラーに係わる不具合モードの属性値が、図示のように階層的に分類されて記述される。この例の不具合モードの属性値は、例えば、抜け、回数の間違い、数え間違い、危険の見逃し、位置の間違い等である。

図７（ｂ）に示す例では、物理現象に係わる不具合モードの属性値が、図示のように電気系／機械系機器故障、加工不具合、組立時の不具合等に分類されて記述される。例えば、電気系機器故障に分類される不具合モードの属性値は、開放、短絡、過熱、漏洩、接触不良等である。例えば、加工不具合に分類される不具合モードの属性値は、加工面ビビリ模様、ワーク傷付け、過磨耗等である。図１５等に示す実体／状態データモデル２００の例では、属性「不具合モード１」、「不具合モード２」について属性値「加工面ビビリ模様」、「ワーク傷付け」等が記述されている。

図８は、故障現象網羅表３３の具体例である。
この故障現象網羅表３３の例も、上記故障モード網羅表３２の例と同様、大別して、図８（ａ）に示すヒューマンエラーベースのものと、図８（ｂ）に示す物理現象ベースのものとに分類される。両方とも、図示の通り、様々な不具合現象と、その不具合現象に対応する上記不具合モード（属性値）とが記述されている。例えば上記不具合モードの属性値「加工面ビビリ模様」に対応する不具合現象は、図８（ｂ）より、「ビビリ模様がある」、「異音がする」であることが分かる。図１５等に示す実体／状態データモデル２００の例では、その属性値が「加工面ビビリ模様」である不具合モードに関連する属性「現象」の属性値は、「ビビリ模様、異音」となっている。

図９は、故障結果網羅表３４の具体例である。
図示の通り、大規模破壊、破壊・損傷、電気故障、システム故障、負傷等の様々な故障結果（属性値）が、階層的に分類・整理されて記述されている。図１５等に示す実体／状態データモデル２００では、属性「結果」に対してこれら属性値が記述される。

図１０は、故障原因網羅表３５の具体例である。
この故障原因網羅表３５の例も、上記故障モード網羅表３２等と同様、大別して、図１０（ａ）に示すヒューマンエラーベースのものと、図１０（ｂ）に示す物理現象ベースのものとに分類される。両方とも、図示の通り、環境調査不足、誤認知、知識不足、管理不良、熱変動、振動、アーク、加工製造方式不良、位置決め精度不良、構造不備、材質不適切等の様々な故障原因（属性値）が、階層的に分類・整理されて記述されている。尚、図１０（ｂ）に示す物理現象ベースの例のように、階層構造が２階層のものと、３階層のものとが混在してもよい。

ここで、図１５等に示す実体／状態データモデル２００の例では、属性名「故障原因（原因）」である属性が存在しないが、例えば図１５の左側に示す「加工製造方式（不良）」、「最大取扱い重量（超過）」等のようにＦＴＡロジックのメソッドの入力と成り得る属性（以下、原因属性と呼ぶ）に対応付けて、故障原因網羅表３５の上記属性値が記述される。

図１１は、故障対策網羅表３６の具体例である。
この故障対策網羅表３６の例も、上記故障モード網羅表３２等と同様、大別して、図１１（ａ）に示すヒューマンエラーベースのものと、図１１（ｂ）に示す物理現象ベースのものとに分類される。両方とも、図示の通り、一体化、ばらつきの除去、指示・記録、ラベリング、動作の検知・表示、サスペンションブッシュばね変更、溶接、加工方法是正、切削条件是正等の故障に対する具体的な対策方法（属性値）が、階層的に分類・整理されて記述されている。図１５等に示す実体／状態データモデル２００では、属性「対策」に対して図示のようにこれら属性値（加工方法是正、脱着部材質是正等）が記述される。

次に、以下、製品・工程モデルＤＢ（データベース）（ＰＰＭＤＢ）２２について説明する。
図１２は、ＰＰＭＤＢ２２に係わる故障因果連鎖の表現モデルについて説明する為の図である。

尚、ここでは、理解し易いように、ＰＰＭＤＢ２２に格納されるデータを、表現モデルの形式で表して説明するが、実際に格納されるデータの構成は、例えば図１３に示すようになる。

図１２に、ＰＰＭＤＢ２２によるユニットの表現モデルの一例を示す。同図に示す故障因果連鎖の表現モデル５０においては、実体は矩形（ボックス）で、状態は楕円で示されている。また、状態遷移は遷移前の実体（または状態）から遷移後の実体（または状態）に向かう矢印で示されている。この表記は、後述する図１４においても同様である。

図１２は実体５１（ユニットＣ）の表現モデル５０であり、実体５１（ユニットＣ）が実体５２（部品Ａ）と実体５３（部品Ｂ）とで構成されるという製品構造情報（Ｅ−ＢＯＭ）と、部品入荷６６をして状態６１（初期（準備））となり、その後、実体５２（部品Ａ）を組付けて状態６２（中間品Ｃ１）となり、その状態６２（中間品１）に実体５３（部品Ｂ）を組付けて状態６３（中間品Ｃ２）となり、その状態６３（中間品Ｃ２）を検査することで状態６４（完成品）となる、すなわち実体５１（ユニットＣ）が完成するという製造工程情報（Ｍ−ＢＯＭ）を表現している。

表現モデル５０は、実体５１（ユニットＣ）の上記製品構造情報と上記製造工程情報を以下に述べるような記述で表現している。実体５１(ユニットＣ）と実体５２(部品Ａ）間及び実体５１（ユニットＣ）と実体５３(部品Ｂ）間を、それぞれ、実体５１(ユニットＣ）に向かう状態遷移を示す矢印７１，７２で接続するように記述する。この記述により、実体５１（ユニットＣ）が実体５２（部品Ａ）と実体５３（部品Ｂ）とから構成されるという実体５１（ユニットＣ）の製品構造情報を表現している。

また、実体５１（ユニットＣ）が状態６１（初期（準備））、状態６２（中間品Ｃ１）、状態６３（中間品Ｃ２）及び状態６４（完成品）という製造工程を経て完成するという記述と、状態６１（初期（準備））に状態遷移を示す矢印６６を入力させ、状態６１（初期（準備））と状態６２（中間品Ｃ１）間を状態６２（中間品Ｃ１）に向かう状態遷移を示す矢印６７で接続し、状態６２（中間品Ｃ１）と状態６３（中間品Ｃ２）間を状態６３に向かう矢印で接続し、状態６３（中間品Ｃ２）と状態６４（完成品）間を状態６４（完成品）に向かう矢印で接続するように記述する。さらに、矢印（状態遷移）６７を矢印（状態遷移）７１と対応付ける記述と、矢印（状態遷移）６８を矢印（状態遷移）７２に対応付けるよう記述する。さらに、状態遷移６６が行われる条件（状態遷移条件（ここでは工程））が「部品入荷」、状態遷移６７，６８が行われる条件が「組立」、状態遷移６８が行われる条件が「検査」である旨を記述する。これらの記述により、まず、部品入荷して実体６１（初期（準備））の状態となり、まず実体５２（部品Ａ）を組み立てて実体６２（中間品Ｃ１）の状態となり、実体６２（中間品Ｃ１）に実体５３（部品Ｂ）を組み立てて実体６３（中間品Ｃ２）となり、この実体６３（中間品Ｃ２）を検査して、実体５１（ユニットＣ）が完成するという実体５１（ユニットＣ）の製造工程情報が表現されている。

実体５２（部品Ａ）と実体５３（部品Ｂ）についても、実体５１（ユニットＣ）と同様にして製造工程情報を記述している。
実体５２（部品Ａ）に関しては、状態８１（原材料）、状態８２（中間品Ａ１）、状態８３（中間品Ａ２）、状態８４（中間品Ａ３）及び状態８５（完成品）を、順に、矢印（状態遷移）８６〜９０で連結し、 矢印（状態遷移）８６が行われる条件が「原材料入荷」、矢印（状態遷移）８７が行われる条件が「切削」、矢印（状態遷移）８８が行われる条件が「研磨」、矢印（状態遷移）８９が行われる条件が「表面処理」及び矢印（状態遷移）９０が行われる条件が「検査」であることを記述している。この記述により、実体８１（原材料）を入荷し、その実体８１（原材料）を切削して実体８２（中間品Ａ１）にし、その実体８２（中間品Ａ１）を研磨して実体８３（中間品Ａ２）にし、その実体８３（中間品Ａ２）を表面処理して実体８４（中間品Ａ３）にし、その実体８４（中間品Ａ３）を検査して実体８５（完成品）、つまり、実体５２（部品Ａ）が完成するという製造工程情報が表現されている。

実体５３（部品Ｂ）に関しては、状態９１（原材料）、状態９２（中間品Ｂ１）、状態９３（中間品Ｂ２）及び状態９４（完成品）を、順に、矢印（状態遷移）９６〜９９で連結し、 矢印（状態遷移）９６が行われる条件が「原材料入荷」、矢印（状態遷移）９７が行われる条件が「鍛造」、矢印（状態遷移）９８が行われる条件が「熱処理」及び矢印（状態遷移）９９が行われる条件が「検査」であることを記述している。この記述により、実体９１（原材料）を入荷し、その実体９１（原材料）を鍛造して実体９２（中間品Ｂ１）にし、その実体９２（中間品Ｂ１）を熱処理して実体９３（中間品Ｂ２）にし、その実体９３（中間品Ｂ２）を検査して実体９４（完成品）、つまり、実体５３（部品Ｂ）が完成するという製造工程情報が表現されている。

図１３は、図１２に示す表現モデルを情報処理装置のメモリやストレージに格納する場合のデータ構造を示す図である。
図１３に示すテーブル（ＰＰＭ情報）１００は、実体コード１０１、状態コード１０２、前状態コード１０３、状態遷移順１０４、状態遷移コード１０５、入力品目コード１０６、出力品目コード１０７及び構成フラグ１０８の各項目を、図１２に示す各実体毎に格納している。上記各コードの定義は以下のとおりである。

実体コード１０１・・・ユニットや部品などの実体に一意的に割り当てるコード
状態コード１０２・・・各種状態に一意的に割り当てられるコード
前状態コード１０３・・・状態コード１０２が示す状態に遷移する前の状態の状態コード
状態遷移順・・・ある一つのユニットや部品などの実体が完成されるまでの製造工程における状態の遷移順序を示すシリアル番号。１から順に割り当てられる
状態遷移コード・・・状態遷移が行われる条件（状態遷移条件（工程））を示すコード
入力品目コード・・・ユニットや部品などの各実体の各製造工程において使用（入力）される品目（状態）に一意的に割り当てられるコード
出力品目コード・・・ユニットや部品などの各実体の各製造工程において製造（出力）される品目（状態）に一意的に割り当てられるコード
構成フラグ・・・ユニットなどの実体を構成するサブ実体（部品）を示す上記実体コード１０１
テーブル１００には、部品Ａ（実体５２）、部品Ｂ（実体５３）及びユニットＣ（実体５１）の各実体について、状態遷移（製造工程）における各状態（工程）毎に、その情報が格納されている。部品Ａについては、原材料（状態８１）、中間品１（状態８２）、中間品２（状態８３）、中間品３（状態８４）及び完成品（状態８５）の状態コード１０２が格納されており、原材料（状態８１）を除く他の状態について前状態コード１０３が格納されている。状態コード１０２と前状態コード１０３とにより、状態遷移による状態の変化が分かる。

また、部品Ａの各状態について状態遷移順１０４が設定されており、この状態遷移順１０４を基に部品Ａが完成するまでの状態遷移の順序を知ることができる。さらに、部品Ａの各状態コード１０１について状態遷移コード１０５が設定されている。この状態遷移コード１０５は、対応する状態コード１０１で示される状態に対して施す作業（工程）を示すコードとなっている。部品Ａの「原材料入荷」以外の状態遷移コード１０５に対して入力品目コード１０６が設定されている。

この入力品目コード１０６で示される状態は、状態遷移コード１０５で示される作業（工程）の対象となる状態である。部品Ａの各状態遷移コード１０５に対して出力品目コード１０７が設定されている。この出力品目コード１０７で示される状態は、対応する入力品目コード１０６が設定されていない場合は状態コード１０１で示される状態と通常は同じであり、対応する入力品目コード１０６が設定されている場合には入力品目コード１０６で示される状態に状態遷移コード１０５で示される作業（工程）により作成される状態である。

部品Ｂについても、図１２の表現モデル５０に基づいて実体コード１０１〜出力品目コード１０７までの各項目が設定されている。部品Ｂのテーブル１００に設定する各コードなどの項目内容は部品Ａと同様な形式なので、ここでは、詳しい説明を省略する。

ユニットＣ（実体５１）も、部品Ａ（実体５２）と同様に、図１２の表現モデル５０に基づいてテーブル１００に必要な項目が設定される。ユニットＣの場合には、さらに、構成フラグ１０８に、部品Ａと部品Ｂのフラグが設定される。すなわち、実体コード１０１にユニットＣが設定されている行で、かつ状態遷移コード１０５が「組立」と設定された２つの行の構成フラグ１０８に、それぞれ、「部品Ａ」と「部品Ｂ」の実体コード１０１が設定される。このようなテーブル１００への設定により、“ユニットＣが部品Ａと部品Ｂにより構成される”というユニットＣの製品構造情報を知ることができる。

上記のようにＰＰＭ情報は、製品の構成構造、及び、実体(製品または部品)を製造する工程の構成、関係、順番(シーケンス)を定義するものである。工程(状態遷移条件)を実行した結果、次の状態へと遷移することになる。

図１４は、ＰＰＭＤＢ２２に基づく故障メカニズムの表現イメージを示す図である。
同図に示す表現モデル１１０は、図１２に示す表現モデル５０での記述に、さらに、ハザード及びその伝播路と方向を示す記述を加えたものとなっているが、実際には、ＰＰＭＤＢ２２には、このような表現モデルに対応するデータが格納されるわけではなく、あくまでもイメージを示しているに過ぎない。実際にＰＰＭＤＢ２２に格納されるデータは、例えば図１３に示すデータであり、図１４に示すようなハザードやハザードの伝播に相当するデータは格納されない。図１４に示すようなハザードやハザードの伝播およびインタフェースは、ＰＰＭＤＢ２２に基づいて品質知識ＤＢ２３の格納データを作成する段階で人手によって記述されるものであり、これについては後に説明する。これは、ハザードやその伝播だけでなく、可能な故障モードや相互作用についても同様である。

ここで、ハザードとは、実体に不具合を引き起こす潜在的もしくは顕在的な危険源である。ハザードには、例えば、環境に関するもの、リソースに関するもの、人的なものなどがある。環境に係るハザードの例としては、作業スペースの狭さ、振動、高温など、リソースに関するハザードの例としては、作業手順不備、工具過磨耗など、人的なハザードの例としては、事前検討不足、作業ミス、手順無視、寝不足などがある。

図１５に、製品・工程モデルＤＢ２２に基づいて作成される実体／状態データモデルの一例を示す。
実体／状態データモデル２００は、各実体（ユニット、部品）毎に作成される。

図示の実体／状態データモデル２００は、大別して、入力部２０１、出力部２０２、各種の判定ユニット（メソッド）２０３（メソッド２０３ａ〜２０３ｅ）より成る。あるいは、別の見方で大別すると、各実体（ユニット、部品）の完成形に対応する実体データモデル２０４と、各実体（ユニット、部品）を完成させるまでの各製造工程・プロセス（各状態）に対応する状態データモデル２０５とに分かれる。

入力部２０１、出力部２０２には、例えばストレス、ストレングス、不具合モード、部位、現象、結果、対策等の属性等とその属性値が記述される。上記の通り、不具合モード、部位、現象、結果、対策等の属性や上記原因属性に係わる属性値は、上述した各種網羅表を参照して記述することができ、表現の標準化が図れるので、従来の「情報の表現、記述には個人差が大きい為、活用し難い」という問題を解消できる。ストレス、ストレングスは、主にＳＳＭロジックの入力に用いられるものであり、不具合モードの発生条件を表現する。

また、入力部２０１、出力部２０２の記述項目は、全てが上記網羅表に基づいて記述されるとは限らない。例えば設計や製造上のノウハウ情報を設計書、規格書、基準書等を用いて記述するものがあってよい。あるいは、図示の規格・基準書リンク、冶具使用ガイドリンク等のように、知見・ノウハウを有する関連ドキュメントの保存場所（電子ファイルなら絶対パス、等、紙ファイルなら置いてある棚の場所等）へのリンクを張ることもできる。これによって、後にこれらの関連ドキュメントを参考情報として参照したいときに、容易に参照することができる。尚、関連ドキュメントとは、図示の例では、設計仕様、設計ノウハウ、設備基準書、冶具基準書、工具基準書、製造要領書、材料基準書等である。

尚、例えば「加工製造方式（不良）」といった表記は二つの情報を意味することができ、一つは属性「加工製造方式」が属性値「切削加工」等であるという情報（網羅表以外から記述した場合）、もう一つは原因属性が属性値「加工製造方式不良」であるという情報（網羅表から記述した場合）である。

実体／状態データモデル２００の骨組みは、各種業務等のノウハウを活かして作成されたテンプレート（後述する）を用いて、自動的に作成される。
判定ユニット（メソッド）２０３は、分析業務のノウハウを活かして作成されるメソッドロジックである。メソッドには、例えば図示のＳＳＭロジックによるメソッド２０３ａ、ＦＴＡロジックによるメソッド２０３ｂ〜２０３ｅがあり、他にもＦＭＥＡロジックによるメソッド等があり、詳しくは後述する。

上記実体／状態データモデル２００は、概略的には、生産活動における各種の情報・知見・ノウハウの持ち方を表しているものである。実体／状態データモデル２００により情報・知見・ノウハウの持ち方が整備され、生産活動における各種の情報・知見・ノウハウをこのモデル２００の属性及び属性値、ないしメソッドロジックとして格納することにより、情報・知見・ノウハウを関連付けて体系的に蓄積・利用することが可能となる。例えば、メソッド２０３ｃに係わる入出力を見れば、加工製造方式不良、最大取扱える重量超過によって、リム部に不具合モード１「加工面ビビリ模様」が発生すること、更に不具合発生時の現象はビビリ模様、異音であり、その結果「破壊・損傷」が生じること、不具合対策として「加工方法是正」があることが一目で分かる。更に、当該部品／ユニットの製造工程中に発生する不具合モード１「加工面ビビリ模様」が、完成した部品／ユニットに影響を与えること（ハザードの伝播）が、一目で分かる。これは、図中の表現においては、メソッド２０３ｃからの出力が、メソッド２０３ｂの入力となる矢印によって示される。尚、同様にして、ある状態（製造工程）から次の状態へのハザードの伝播も記述することができる。

品質知識ＤＢ２３には、上記実体／状態データモデル２００を複数用いたデータモデルが格納されることになる。これについて、以下、図１６以降を参照して説明する。
ここで、以下の図１６以降の図面及び説明では、実体／状態データモデル２００は、図１５に示す例のように属性名、属性値、その他（リンク等）を詳細に示すことはせず、簡略化して示すものとし、主な属性名のみを示すものとする。

図１６に示す例は、“製品・工程モデルＤＢ２２を用いた故障メカニズムのユニット表現例”２５に格納される故障因果連鎖の表現モデルに基づいて、各部品とユニットの実体／状態データモデル２００の基礎（骨組み）と、これらの関係（実体間の構造関係、工程の構成の順序）を自動作成して、更に人手によってメソッドの作成や属性値の入力やハザードとハザード伝播の記述等を行ってデータモデルを完成させるイメージを示し、完成後の状態を、図１６の図上右側の品質知識ＤＢ２３内に示す。図示の各矢印（例えば部品Ａの属性「（不具合）モード」から部品Ｂの属性「ストレス３」に向かう矢印等）は、ハザードの伝播等を示すものであり、これらも人手によって記述する。特に部品間の伝播路は“インタフェース”によるもので、人が“インタフェース”を定義することにより成り立つものである。尚、図１６では、“製品・工程モデルＤＢ２２を用いた故障メカニズムのユニット表現例”２５の格納内容は、図１４と同様、ハザードとハザード伝播のイメージも示しているが、上記の通り、これらは実際には製品・工程モデルＤＢ２２には格納されておらず、品質知識ＤＢ２３のデータモデル作成の際に、人間が判断して記述する。

上記図１６に示すように作成されたデータモデルに対して、更に人手による判断・入力によって、例えば図１７に示すような追加入力／変更作業を行ってもよい。すなわち、分析ロジック（メソッド）の変更、ＦＭＥＡのパラメータ変更、不具合（故障）モードを属性として追加、影響度の属性値を入力等を行ってもよい。勿論、このような例に限るものではない。これらの追加入力／変更作業は、例えば予めデータベースに格納されている各種情報（過去の不具合原因・対策、工程設計知見・ノウハウ、設計ＦＭＥＡ情報、製造知見・ノウハウ等）を参照して、行ってもよい。

上述した実体／状態データモデル２００の基礎（骨組み）とこれらの関係を自動作成方法について、以下、図１８〜図２０を参照して説明する。
尚、ここでは、製品・工程モデルＤＢ２２に格納されるデータの例として、上記図１３に示した例（ＰＰＭ情報１００）を参照して説明する。

図１８は、上記ＰＰＭＤＢ情報１００に基づく品質知識ＤＢ２３の情報の作成処理フローチャート図である。
図１８において、まず、製品・工程モデルＤＢ２２から上記ＰＰＭ情報１００を取得する（ステップＳ１１）。

次に、取得したＰＰＭＤＢ情報１００に基づいて、まず構成フラグ１０８により、製品構成情報、各実体及び各実体を構成する要素（サブ実体）を階層的に抽出する（ブロック、ユニット、部品等）（ステップＳ１２）。図１２、図１３の例では、ユニットＣを構成するサブ実体は部品Ａと部品Ｂということになる。尚、図１２、図１３には簡単な例を示したが、実際には、更に上位階層、すなわちブロック等が存在し、ブロックは複数のユニットまたは部品によって構成される。

続いて、抽出された各実体（サブ実体も含む）に対応する実体データモデル雛型（テンプレート）を、不図示のデータベースから取得する（ステップＳ１３）。すなわち、予め、各実体毎に対応する実体データモデル雛型が作成されて不図示のデータベースに格納されている。図１３の例では、部品Ａ、部品Ｂ、及びユニットＣのそれぞれに対応する実体データモデル雛型を、不図示のデータベースから取得することになる。図１８の図上左側には、ユニットＣ用の実体データモデル雛型２１１、部品Ａ用の実体データモデル雛型２１２の一例を示す。尚、図示していないが、当然、部品Ｂ用の実体データモデル雛型も存在し、これを取得する。

そして、上記製品構成情報と、取得した各種実体データモデル雛型とを用いて、プロダクトモデル対応のデータ構造２１４を作成する（ステップＳ１４）。図１９（ａ）に、図１８の例に対応するプロダクトモデル対応のデータ構造２１４を示す。図１９（ａ）に示すように、プロダクトモデル対応のデータ構造２１４は、ステップＳ１３で取得した各種実体データモデル雛型を配置し、且つ製品構成情報、すなわちユニットＣが部品Ａと部品Ｂより成ることを示す情報（図上、矢印で示す）より成る。

更に、予め、各実体の各種状態毎に対応する各種状態データモデル雛型（テンプレート）が作成され、不図示のデータベースに格納されている。これより、ステップＳ１１で取得したＰＰＭＤＢ情報１００の状態コード１０２より、各状態コード１０２に対応する状態データモデル雛型２１３を、不図示のデータベースから取得する（ステップＳ１５）。そして、ステップＳ１４で作成してあるプロダクトモデル対応のデータ構造２１４における各実体データモデル雛型に対して、ステップＳ１５で取得した状態データモデル雛型を、状態遷移順１０４の順番に従って、順次、追加していくことで、プロダクト・プロセスモデル対応（プロダクトモデル＋状態データモデル対応）のデータ構造２１５を作成する（ステップＳ１６）。

（プロダクトモデル＋状態データモデル）対応のデータ構造２１５の一例を、図１９（ｂ）に示す。図１９（ｂ）に示すように、各実体毎に、（プロダクトモデル＋状態データモデル）が作成される。すなわち、ユニットＣに対応する（プロダクトモデル＋状態データモデル）２２１、部品Ａに対応する（プロダクトモデル＋状態データモデル）２２２、部品Ｂに対応する（プロダクトモデル＋状態データモデル）２２３が作成される。

ここで、上記の通り、上記各種テンプレート（実体データモデル雛型、状態データモデル雛型）は、予め作成されているものであるが、その作成方法について、簡単に説明しておく。

上記各種テンプレートは、その部品（またはユニット）あるいは製造過程毎に関係する業務毎に、その業務の特質に基いて人が整理して作成する。
実体データモデル雛型の場合は、製品設計情報(知見・ノウハウ含む)から整理・作成する。これは、製品の設計業務に関する情報・知見・ノウハウであり、ユニットまたは部品の機能性、性能、材料(材質)、幾何形状などの仕様情報、業務等基準書、品質等標準書（これらはノウハウに相当するもの）、更に過去の設計不良による不具合情報(現象、原因、対策等)(これらは知見・ノウハウに相当するもの)等である。

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

尚、実際の実装に関しては、テンプレートの見せ方では入出力を意識する場合、左側の属性群は入力に相当、右側の属性群は出力に相当するが、ローカル変数として利用する場合、左側と右側との区別は特に必要ない。つまり、内部的には左右どちらでも入力または出力として利用できる。

以上説明した処理によって実体／状態データモデル２００の骨組み（初期状態）２２１〜２２３を自動作成したら、その後は、人手による判断、追加入力作業によって、実体／状態データモデル２００を完成させる。

まず、判定ユニット３３及びその入出力関係を追加する処理について、図２０を参照して説明する。
まず、図２０（ｃ）には、判定ユニット（メソッド）２０３及びその入出力関係を追加する作業を行った結果を示す。同図には、判定ユニット２０３として、メソッドｄ、メソッドｅの２つのユニットを追加した状態の実体／状態データモデル２３１，２３２，２３３を示している。また、メソッドｄを例にすると、その入出力関係は、入力がストレス１、ストレス２、ストレングス１、ストレングス２であり、出力はモードまたは不具合３である。

また、メソッドｄの具体例を図２０（ａ）に示す。これは、ＳＳＭロジックに相当する例である。すなわち、入力するストレス、ストレングスに対して、ｉｆ−ｔｈｅｎルールを利用して、対応する不具合モードが真か否かを判定する。

尚、既知の事であるが、一応説明しておくならば、ストレングスとは設計、評価すべき不具合モードの耐性や機能性を表す総合的特性であり、ストレスはあるストレングスをもつ対象に与えられる不具合モードを引き起こす駆動力であり、不具合モードは因果連鎖に関わり、着目対象に発生する望ましくない現象、状態、特性変化等である。

また、メソッドｅは、状態２（図１２の中間品Ｃ１等）に対応する状態データモデルにおける入力中の設備（設備不良（確率））、工具（工具不良（確率））、製造法（製造法不良）、製造条件、及び作業手順を入力とし、完成品における不具合３や、中間品（状態２）における不具合２に対して出力を行う。メソッドｅの具体例は、例えば図２０（ｂ）に示すようにＦＴＡロジックに相当する、ＡＮＤ論理積、ＯＲ論理和の結合により、故障あるいは破損のメカニズムを階層的に表現するものである。

尚、メソッドｄ，ｅ等のような各種メソッドロジックは、予め作成されてメソッドライブラリ等に登録されていれば、これを選択して利用し、作成されたものがなければ、その都度、ユーザが作成する。

また、メソッドは、上記ＳＳＭロジック、ＦＴＡロジックによるメソッドに限らず、例えばＦＭＥＡロジックに相当するメソッドもある。
図２１に、ＦＭＥＡロジックに相当するメソッドの一例を示す。

上述してあるように、ＦＭＥＡの手法では、故障（不具合）モードの危険優先度（危険優先数）を発生頻度・影響度・検出難易度に基づいてランク付けする。危険優先数は、図示の通り、発生頻度×影響度×検出難易度により算出する。各不具合モード１〜ｎについて各々危険優先数を求め、これらを大小比較して、ランク付けを行うことになる。

また、本例の知見・ノウハウの体系化装置１０では、図１の登録機能部１２によって、図２２で説明する属性値の登録支援処理を行うことができる。
上記自動作成した実体／状態データモデル２００の骨組み（初期状態）２２１〜２２３では、例えばモード（故障モード）、現象３、原因２、対策２等の属性が格納されているが、各属性に対応した具体的な属性値は未だ登録されていない。

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

これによって、データ登録の手間を省き、また入力者がベテランであっても初心者であっても関係なく、属性値の記述を平準化できる。更に、マスタテーブルのメンテナンス権限を管理することにより、各種マスタテーブルの内容が勝手に変更されないようにすることで、データの一貫性を保証できる。

尚、登録機能部１２は、上記の機能に限らず、網羅表（そのマスタテーブル）自体の登録を行わせる機能も有していてもよい。
更に、各種マスタテーブルから選択した属性値を、知識データＤＢ２４に格納される知見・ノウハウシートにも記述するようにしてもよい。

更に、上述した属性だけでなく、他の属性（影響度、頻度、確率データ等）も含めて、実体／状態データモデル２００の属性値を更新したり、新たな属性を追加することにより、知見・ノウハウが更新され、システムは進化できる。

属性値の更新は、例えば、
・発生頻度(属性)に関する属性値を、２回／月から３回／月に更新
・耐性(ストレングス)(属性)に関する属性値を、-30℃〜＋50℃から-20℃〜＋55
℃に更新
・影響度(属性)に関する属性値を、２から５に更新
等である。

ここで、進化とは、上記属性値の更新等によって、分析の結果が変わってくることを意味する。例えば、影響分析では影響度の大きい方に左右されるので、影響度が変われば、今までの分析と変わる方向に結果を導くこととなる。また、属性の追加により、分析の流れも変わってくる可能性がある。なお、工程(状態)の追加、削除、変更も容易であるので、工程の追加、削除、変更による進化については言うまでもなく、進化しやすい仕組みとなっている。

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

図２３は、図１の参照機能部１３による参照機能について説明する為の図である。
上述した知見・ノウハウの体系化装置１０はＬＡＮ等のネットワーク２４０に接続しており、各現場（製品設計／生産準備／量産製造）に設けられている情報処理端末（不図示）から、ネットワーク２４０を介して知見・ノウハウの体系化装置１０にアクセスして、知識データＤＢ２４や品質知識ＤＢ２３から抽出する知見・ノウハウを参照することができる。例えば、品質改善のための業務の為に担当者等が参照する。あるいは、既存設計情報４０２または既存生技情報を参考にして新規製品を開発する業務において、開発担当者等が上記知見・ノウハウを参照して開発に役立てて、変更後設計情報４０２−１、変更後生技情報４０４−１を作成する。または、当該開発業務において、開発担当者等は、知識データＤＢ２４や品質知識ＤＢ２３から抽出するＦＭＥＡ、ＦＴＡ情報を、新規製品の信頼性設計に利用する。

また、上記実体／状態データモデル２００に基づいて、知見・ノウハウ利用のチェックを行う為のチェックシートを生成してもよい。
図２４に、チェックシート生成の一例を示す。

図示のチェックシート２５０は、チェック対象２５１とチェック要項２５２より成る。チェック対象２５１は、概念区分を行っているものであり、図示の例では、大区分、中分類、小区分の３階層に区分している。チェック要項２５２には、この概念区分で階層的に分類されてなる各小区分毎に、それに関連する各チェック項目が洗い出されて項目１、項目２、項目３、等として格納される。尚、各チェック項目の具体例は特に示さないが、図上では例えば小区分「鉄（金属）」に関連するチェック項目は「あ、い、う、え、お」等として示してある。

上記チェック対象２５１とチェック要項２５２は、実体／状態データモデル２００に基づいて記述する。上記チェック対象２５１は、実体／状態データモデル２００の入力部２０１の記述内容に基づいて記述される。入力部２０１の記述内容の中で、属性（属性名）は、大区分、中分類に、属性値は小区分に記述される。尚、属性は、体系化された設計・製造アイテムであり、属性値はこのアイテムの内容である。これは、例えば任意の属性（名）をキーにして実体／状態データモデル２００を検索して求める。図示の例では、例えば、属性「材質」について品質知識ＤＢ２３を検索した結果、属性値「鉄（金属）」、「アルミ」、及び「プラスチック」が得られた例を示している。チェック要項２５２は、不具合対策、設計／製造ノウハウ・要領等を記述するものであり、これらは各属性値に対応したものを、実体／状態データモデル２００の出力部２０２の記述内容から抽出するものである。

チェックシートは、例えば設計変更の際に、変更した部分のチェックや変更漏れをチェックする際に利用できる。
図２５は、上述した知見・ノウハウの体系化装置１０を実現するコンピュータのハードウェア構成の一例を示す図である。

同図に示すコンピュータ３００は、ＣＰＵ３０１、メモリ３０２、入力部３０３、出力部３０４、記憶部３０５、記録媒体駆動部３０６、及びネットワーク接続部３０７を有し、これらがバス３０８に接続された構成となっている。同図に示す構成は一例であり、これに限るものではない。

ＣＰＵ３０１は、当該コンピュータ３００全体を制御する中央処理装置である。
メモリ３０２は、プログラム実行、データ更新等の際に、記憶部３０５（あるいは可搬型記録媒体３０９）に記憶されているプログラムあるいはデータを一時的に格納するＲＡＭ等のメモリである。ＣＰＵ３０１は、メモリ３０２に読み出したプログラム／データを用いて、上述してある各種処理（図１の各機能部の処理、図１８に示す処理等）を実行する。

入力部３０３は、例えば、キーボード、マウス等である。
出力部３０４は、例えばディスプレイ等である。
ネットワーク接続部３０７は、例えばイントラネットやインターネット等のネットワークに接続して、他の情報処理装置とのコマンド／データ送受信を行う為の構成である。

記憶部３０５は、例えばハードディスク等であり、上述した様々な処理・機能を、コンピュータ３００に実行させるためのプログラム／データ（図１８の処理等を実行させるプログラム、及び図１７に示す各種データベースのデータ等）が格納される。

あるいは、これらプログラム／データは、可搬型記録媒体３０９に記憶されているものであってもよい。この場合、可搬型記録媒体３０９に記憶されているプログラム／データは、記録媒体駆動部３０６によって読み出される。可搬型記録媒体３０９とは、例えば、ＦＤ（フレキシブル・ディスク）３０９ａ、ＣＤ−ＲＯＭ３０９ｂ、その他、ＤＶＤ、光磁気ディスク等である。

あるいは、また、上記プログラム／データは、ネットワーク接続部３０７により接続しているネットワークを介して、他の装置内に記憶されているものをダウンロードするものであってもよい。あるいは、更に、インターネットを介して、外部の他の装置内に記憶されているものをダウンロードするものであってもよい。

また、本発明は、上記本発明の各種処理をコンピュータ上で実現するプログラムを記録した可搬型記憶媒体として構成できるだけでなく、当該プログラム自体として構成することもできる。

知見・ノウハウの体系化装置の機能ブロック図である。 知見・ノウハウの体系化装置と、これに係わるシステム全体の処理フローを示す。 知見・ノウハウの体系化装置と既存手法について概略的に説明する為の図である。 全体的な入出力のイメージを示す図である。 網羅表の種類を示す図である。 故障部位網羅表の具体例である。 故障モード網羅表の具体例である。 故障現象網羅表の具体例である。 故障結果網羅表の具体例である。 故障原因網羅表の具体例である。 故障対策網羅表の具体例である。 故障因果連鎖の表現モデルについて説明する為の図である。 図１２に示す表現モデルを情報処理装置のメモリやストレージに格納する場合のデータ構造を示す図である。 故障メカニズムのユニット表現イメージを示す図である。 製品・工程モデルＤＢに基づいて作成される実体／状態データモデルの一例を示す。 製品・工程モデルＤＢに基づく品質知識ＤＢのデータ構築イメージを示す図（その１）である。 製品・工程モデルＤＢに基づく品質知識ＤＢのデータ構築イメージを示す図（その２）である。 ＰＰＭＤＢ情報に基づく品質知識ＤＢの情報の作成処理フローチャート図である。 （ａ）、（ｂ）は、図１８の処理途中、処理結果として作成されるプロダクトモデル対応のデータ構造、（プロダクトモデル＋状態データモデル）対応のデータ構造の一例を示す図である。 （ａ）、（ｂ）はＳＳＭ、ＦＴＡロジックによるメソッドの具体例、（ｃ）は図１９（ｂ）に示す自動作成結果に対してメソッドを追加記述した例を示す図である。 ＦＭＥＡロジックによるメソッドの具体例を示す図である。 網羅表に基づく属性値の登録支援機能を説明する為の図である。 データベースの参照機能を説明する為の図である。 実体／状態データモデルに基づくチェックシートの生成とその一例を示す図である。 コンピュータハードウェア構成図である。 従来の設計、生産準備、量産製造における情報の流れを示す図である。 従来の不具合対応処理の業務フローを示す図である。

符号の説明

１０ 知見・ノウハウの体系化装置
１１ 体系化・蓄積機能
１２ 登録機能部
１３ 参照機能部
２１ 網羅表ＤＢ２１
２２ 製品・工程モデルＤＢ（ＰＰＭＤＢ）
２３ 品質知識ＤＢ（ＱＡ２−ＫＤＢ）
２４ 知識データＤＢ
２５ 製品・工程モデルＤＢを用いた故障メカニズムのユニット表現例
３１ 故障部位網羅表
３２ 故障モード網羅表
３３ 故障現象網羅表
３４ 故障結果網羅表
３５ 故障原因網羅表
３６ 故障対策網羅表
５０ 故障因果連鎖の表現モデル
５１ 実体（ユニットＣ）
５２ 実体（部品Ａ）
５３ 実体（部品Ｂ）
６１ 状態（初期（準備））
６２ 状態（中間品Ｃ１）
６３ 状態（中間品Ｃ２）
６４ 状態（完成品）
６６〜６９ 矢印（状態遷移）
７１、７２ 矢印（状態遷移）
８１ 状態（原材料）
８２ 状態（中間品Ａ１）
８３ 状態（中間品Ａ２）
８４ 状態（中間品Ａ３）
８５ 状態（完成品）
８６〜９０ 矢印（状態遷移）
９１ 状態（原材料）
９２ 状態（中間品Ｂ１）
９３ 状態（中間品Ｂ２）
９４ 状態（完成品）
９６〜９９ 矢印（状態遷移）
１００ テーブル（ＰＰＭ情報）
１０１ 実体コード
１０２ 状態コード
１０３ 前状態コード
１０４ 状態遷移順
１０５ 状態遷移コード
１０６ 入力品目コード
１０７ 出力品目コード
１０８ 構成フラグ
１１０ 故障メカニズムのユニット表現
２００ 実体／状態データモデル
２０１ 入力部
２０２ 出力部
２０３ 判定ユニット（メソッド）
２０４ 実体データモデル
２０５ 状態データモデル
２１１、２１２ 実体データモデル雛型
２１３ 状態データモデル雛型
２１４ プロダクトモデル対応のデータ構造
２１５ プロダクト・プロセスモデル対応のデータ構造
２２１ ユニットＣに対応する（プロダクトモデル＋状態データモデル）
２２２ 部品Ａに対応する（プロダクトモデル＋状態データモデル）
２２３ 部品Ｂに対応する（プロダクトモデル＋状態データモデル）
２３１〜２３３ 実体／状態データモデル
２４１ マスタテーブル
３００ コンピュータ
３０１ ＣＰＵ
３０２ メモリ
３０３ 入力部
３０４ 出力部
３０５ 記憶部
３０６ 記録媒体駆動部
３０７ ネットワーク接続部
３０８ バス
３０９ 可搬型記録媒体

Claims (7)

1. プロダクト構造ベースでの情報表現モデルとプロセス構造ベースでの情報表現モデルを統合した統合モデルをデータベース化して格納する統合モデル格納手段と、
   前記統合モデルに基づいて、該統合モデルによって示される各実体、状態の各々について予め用意されている、少なくとも各実体または状態に関連する各種対象事象を属性として定義したテンプレートを用いて、実体/状態データモデルの骨組みを作成する実体/状態データモデル作成手段と、
   前記実体/状態データモデルの骨組みに基づいて、前記各属性に対応する属性値、該属性値を用いた各種判定を行うメソッド、ハザード伝播を記述してなるデータモデルを作成させて格納する知見・ノウハウ体系化／蓄積手段と、
   を有することを特徴とする知見・ノウハウの体系化支援装置。
2. 前記各実体の機能を設計する過程から製造する過程までの全ての知見・ノウハウを、前記実体/状態データモデルにおける各属性の属性値として格納することを特徴とする請求項１記載の知見・ノウハウの体系化支援装置。
3. 予め前記各種対象事象を階層的に網羅的に整理してその属性値を記述した各種網羅表を格納する網羅表格納手段と、
   前記各種網羅表に基いたマスタテーブルを表示して任意の属性値を選択させることで、前記実体/状態データモデルにおける任意の属性に対応する属性値を登録させるデータ登録支援手段と、
   を更に有することを特徴とする請求項２記載の知見・ノウハウの体系化支援装置。
4. 前記マスタテーブルのメンテナンス支援手段を更に有することを特徴とする請求項３記載の知見・ノウハウの体系化支援装置。
5. プロダクト構造ベースでの情報表現モデルとプロセス構造ベースでの情報表現モデルを統合した統合モデルに基づいて、該統合モデルによって示される各実体、状態の各々について予め用意されている、少なくとも各実体または状態に関連する各種対象事象を属性として定義したテンプレートを用いて、実体/状態データモデルの骨組みを作成することを特徴とする実体/状態データモデル作成方法。
6. コンピュータに、
   プロダクト構造ベースでの情報表現モデルとプロセス構造ベースでの情報表現モデルを統合した統合モデルを格納する機能と、
   前記統合モデルによって示される各実体、各実体の製造途中の状態、状態遷移、実体間の構成関係に基づいて作成される、各実体毎に該実体とその実体に関係する状態に関連する各種対象事象が属性として定義され、前記各属性に対応する属性値、該属性値を用いた各種判定を行うメソッド、ハザード伝播が記述されてなる実体/状態データモデルと、該実体/状態データモデル間の構成関係の記述を格納する機能と、
   を実現させるためのプログラム。
7. 前記統合モデルに基づいて、該統合モデルによって示される前記各実体、各状態の各々について予め用意されている、少なくとも各実体または状態に関連する各種対象事象を属性として定義したテンプレートを用いて、前記実体/状態データモデルの骨組みを作成する機能、
   を更に有することを特徴とする請求項６記載のプログラム。