JP4691374B2 - 設計支援システム - Google Patents

Description

本発明は、装置の設計を行う際の作業を支援するシステムに係り、特に、設計を行う際の検証対象を的確に把握するためのシステムに関する。

装置の設計を行う際には、製造や市場に出てから不具合を起こさないように、さまざま
な観点での検証が必要である。検証を行うためには、過去の検討内容を把握し、装置の機
構を詳細に解析，検討する必要がある。この検証を確実に行い、故障や不具合を起こさず
、要求される仕様を満たすように、装置を構成する各部品の設計パラメータを決定しなけ
ればならない。

一般には、この検証は、設計者の技量に任されている。このため、設計者がどこまで検
討したかによって、装置の品質が左右されてしまう。これを防ぐため、設計部署では、設
計基準や設計便覧といった教科書的なドキュメントやチェックリスト，デザインレビュー
などを利用することで、品質の維持を図っている。

この設計検討を体系立てて行う手法として、機能オントロジを利用した方法が非特許文
献１で提案されている。

この方法は、製品が果たすべき機能に着目し、機能を詳細化し、その機能を実現するた
めの問題点や別案を体系立てて検討するものである。特に、新規に製品を検討する場合な
どに、問題点の事前把握や対処法、別構成での実現性検討などに有効な手法になっている
。

布瀬雅義他著「生産技術の知識ベースと生産工程改善」精密工学会誌Vol.68,No.4,2002年

非特許文献１で提案されている方法は、装置の概略設計にあたる機能性の検討に関して
は有効であるが、装置の仕様変更や部品変更といった詳細設計の場面での用途まで考慮さ
れていない。

例えば、装置を構成する部品の設計パラメータを変更した場合に、他の構成部品、ある
いは、機能にどのような影響があるかといった情報は、詳細設計を行うにあたり、重要な
情報である。

しかしながら、非特許文献１で提案されている方法は、これら情報を取得するための手
法は考慮されていない。

また、非特許文献１で提案されている機能オントロジを利用した手法では、機能として
の上下関係の関連性は記述できても、機能相互の関連は考慮されていない。つまり、ある
機能性に関して設計パラメータを変更したために、別の機能に波及的に影響があるといっ
た内容は抽出できない。

例えば、部品の厚みを小さくした場合、強度に関する機能の検証だけでなく、強度が変
わったことによるさらなる波及効果に関する機能（部品固定のための機能など）や、振動
モードに関する機能など、機能の上下関係とは関係の無い項目まで検索することはできな
い。

本発明は、装置の設計に関し、設計変更の際の検証対象の把握を容易に行えるようにすることを目的とする。

設計変更にはおおきくわけて２種類ある。ひとつは、製品の外部仕様を変更しようとするもので、もうひとつは製品の外部仕様（性能）を変更せずに実現構造を変更しようとするものである。使い捨てライターを例にとると、前者の例は連続使用時間や着火レスポンスなどをさす。また後者の例は、燃料タンク部の寸法や着火ローラの材質の変更などである。

製品の外部仕様はコンシューマー製品（製品の利用者が一般消費者）である場合は、市場動向から、製品が他の組み立て製品の部品である場合（自動車部品，電子部品）は納め先からの性能アップ要望という形で発生する。それに対して、実現構造の変更は使っていた部品が手に入らなくなったとか、コストダウンのためなどで発生する。

いずれにせよ、設計作業において、設計者が「性能」を直接変更できることは少ない。設計者が直接変更することができるのは製品を構成する部品の寸法や材質であり、これらをいろいろに変更して所定の性能を満たすようにする。例えば、ライターの「連続使用時間」を変更するためには「タンク」の容量を変えるか、単位時間当たりの燃料消費を変えるのが自然だが、これらは、「タンク」や「ノズル」といった部品の寸法変更によって実現される。

従って、設計変更が発生したときに設計者の考え方も自然と異なる。性能が変更しようとするときには、直接いじれる設計項目はどれなのか、性能に影響をあたえる項目，部品，寸法はどれかについてまず考える。また、実現構造の変更が発生したときには、なるべく全体の性能に影響しないように、影響がなるべく狭い範囲でとどまるように考える傾向がある。

特に、ある部品を変更したときに、影響が及んでしまう部品については影響はねかえり部品と呼び、漏れのないように注意を払って考える。簡単な例では、ある部品の寸法を変えたら、組み付いていた部品の寸法も変えなければならないという例である。

例えば、装置を構成する部品の設計パラメータを変更した場合に、他の構成部品に影響を与えるかという手法については公知である。しかし、設計変更の種類について考慮されてはいない。そのため、性能の変更なのか、実現構造の変更なのかによって手法の結果を読み替えなければならなかった。

本発明のもう一つの目的は、設計変更の種類を考慮しながら、構成部品や設計パラメータの変更の影響把握を行えるようにすることを目的とする。

上記課題を解決するため本発明によれば、
設計対象の装置が果たすべき機能を細分化した機能ノード群と、機能を実現するための部品ノード群とが相互の関係を持って表現された機能モデルを生成するためのノードデータを格納するノードデータ格納手段と、
前記ノードデータ格納手段を参照して、機能モデルを生成する機能モデル生成手段と、
前記機能モデルの中から、ノードの指定を受け付けるノード指定受付手段と、
前記指定を受け付けたノードについて、相互の関係を有するノードを抽出するノード抽
出手段と
抽出されたノードを提示する抽出ノード提示手段とを備えることを特徴とする設計支援
システムが提供される。

ここで、相互の関係は、例えば、階層構造の関係とすることができる。

また、前記部品ノードは、それぞれ１または複数の設計パラメータデータを有しており
、
前記機能ノードは、それぞれ、１または複数の動作パラメータおよび目標パラメータを
有しており、
パラメータ同士の組み合わせを規定したパラメータ関連情報を格納するパラメータ関連
情報格納手段と、
前記パラメータ関連情報格納手段を参照して、ノードに含まれるパラメータ同士の関係
を示す機能検証モデルを生成する機能検証モデル生成手段とをさらに備えることができる
。

装置の設計に関し、設計変更の際の検証対象の把握を容易に行うことができる。

本発明の実施の形態について図面を参照して説明する。

図１は本実施形態の設計支援システム１０の構成の一例を示すブロック図である。本図
において、設計支援システム１０は、制御装置１００，表示装置２１０，入力装置２２０
、および、記憶装置３００を備えて構成される。

制御装置１００は、中央処理装置（ＣＰＵ），主記憶装置，ＣＤ−ＲＯＭ・ＤＶＤ−
ＲＯＭ等の可搬性を有する記憶媒体からデータを読み取る読取装置、ネットワークに接続するための通信制御装置等を備えた、一般的な構成を有するサーバコンピュータ、パーソナルコンピュータ等の情報処理装置を用いて構成することができる。もちろん、これに限られない。例えば、設計支援システムのための専用装置として構成することもできる。

制御装置１００には、特徴的な機能部としてデータ編集処理部１１０，機能モデル生成
部１２０，検索処理部１３０が構成される。

データ編集処理部１１０は、設計支援システム１０で用いる各種データの作成・編集を
ユーザが行えるようにするための処理を行う。機能モデル生成部１２０は、記憶装置300に格納された各種データに基づいて、後述する機能モデルを生成するための処理を行う。検索処理部１３０は、機能モデルに関して、ユーザの指示に基づく種々の情報を検索するための処理を行う。

制御装置１００の各処理部は、主記憶装置にロードされた各種プログラムをＣＰＵが実
行することで、情報処理装置上に仮想的に構成される。また、情報処理装置を設計支援シ
ステム１０の制御装置１００として機能させるためのプログラムは、例えば、記憶装置
３００に格納しておくことができる。これらのプログラムはＣＤ−ＲＯＭ，ＤＶＤ−ROM
等の可搬性を有する記憶媒体に記録されることで市場に流通することが可能である。記憶
媒体に記録されたプログラムは、読取装置を介して読み込ませることにより、情報処理装
置にインストールすることができる。また、通信回線を通じて情報処理装置に読み込ませ
るようにすることができる。

表示装置２１０は、ディスプレイ装置等で構成することができ、入力装置２２０は、マ
ウス，キーボードその他の入力デバイスを用いて構成することができる。

記憶装置３００は、ハードディスク装置等を用いて構成することができ、設計支援シス
テム１０で用いる種々のデータをデータベース（ＤＢ）形式で格納する。本実施形態にお
いて、記憶装置３００には、機能ノードＤＢ３１０，部品ノードＤＢ３２０，ノードリン
ク管理ＤＢ３３０，検討実績ＤＢ３４０，方式情報ＤＢ３５０，不具合事例ＤＢ３６０，
履歴ＤＢ３７０が格納されている。

機能ノードＤＢ３１０は、機能モデルを構成する機能ノードに関するデータを管理する
データベースである。ここで、機能モデルは、設計しようとする装置が果たす機能を、装
置の主目的となる機能から順次細分化して階層的に表現していき、最終的に機能を実現す
るための部品を対応させたモデルであり、例えば、図２に示したような構造で表わされる
。本図の例では、設計対象の主目的となる機能を「機能１」とした場合に、その機能を細
分化したものが「機能２」「機能３」となる。そして、「機能２」を実現するための部品
が「部品１」「部品２」であり、「機能３」を実現するための部品が「部品３」であるこ
とを示している。ここで、「機能１」「機能２」等のブロックを機能ノードと呼び、「部
品１」「部品２」等のブロックを部品ノードと呼ぶこととする。なお、以下では、設計対
象の装置としてライターを例に説明を行うものとする。

図３は、機能ノードＤＢ３１０が管理する機能ノードデータのデータ構成の一例を示す
図である。本図に示すように、機能ノードデータは、機能ＩＤ３１０ａ，機能名３１０ｂ，目標仕様３１０ｃ，動作条件３１０ｄ，検討項目３１０ｅを１レコードとして管理する
。

ここで、目標仕様３１０ｃは、さらに、項目とその項目についての値を複数格納するこ
とができ、その機能の出力の条件が定められる。動作条件３１０ｄも、さらに、項目とそ
の項目についての値を複数格納することができ、その機能の入力の条件が定められる。ま
た、検討項目３１０ｅには、その機能を検討する際の項目を複数格納することができる。

機能ノードデータは、設計対象の装置対応に作成されている。また、ユーザは、データ
編集処理部１１０を利用して、機能ノードデータの作成，編集を行うことができる。

図４は、部品ノードＤＢ３２０が管理する部品ノードデータのデータ構成の一例を示す
図である。本図に示すように、部品ノードデータは、部品ＩＤ３２０ａ，部品名３２０ｂ
，設計パラメータ３２０ｃ，ＣＡＤ情報３２０ｄを１レコードとして管理する。

ここで、設計パラメータ３２０ｃは、その部品について設計上考慮すべき項目を示すも
ので、複数格納することができる。また、ＣＡＤ情報３２０ｄは、その部品を設計対象の
装置の一部としてグラフィカルに表現する際のデータを格納する。

部品ノードデータは、設計対象の装置対応に作成されている。また、ユーザは、データ
編集処理部１１０を利用して、部品ノードデータの作成，編集を行うことができる。

図５は、ノードリンク管理ＤＢ３３０が管理するノードリンク管理データのデータ構成
の一例を示す図である。ノードリンク管理データは、機能モデルを構成する各ノードの互
いの関係を規定する。各ノードの関係は、例えば、階層構造で表わすことができ、以下で
は階層構造を例に説明する。ただし、各ノード間の何らかの関係が規定されていれば足り
、階層構造には限られない。

本図に示すように、ノードリンク管理データは、ルート機能ノード３３０ａ，リンク
３３０ｂ，方式３３０ｃを１レコードとして管理する。

ここで、ルート機能ノード３３０ａは、設計対象の装置の主目的となる機能ノードを示
す。リンク３３０ｂは、各ノードの親子関係を示す。また、方式３３０ｃは、後述するよ
うに機能ノードに関連付けられる方式を示す。

ノードリンク管理データは、設計対象の装置対応に作成されている。また、ユーザは、
データ編集処理部１１０を利用して、ノードリンク管理データの作成，編集を行うこと
ができる。

図６は、検討実績ＤＢ３４０が管理する検討実績データのデータ構成の一例を示す図である。検討実績データは、ある機能ノードに関連して検討を行った場合の検討内容を記録するためのデータである。本図に示すように検討実績データは、検討実績ＩＤ３４０ａ，対象機能ＩＤ３４０ｂ，検討日時３４０ｃ，検討時間３４０ｄ，検討方法３４０ｅ，検討条件３４０ｆ，検討結果３４０ｇを１レコードとして管理する。

ユーザは、ある機能ノードに対して検討を行った場合には、データ編集処理部１１０を利用して、ノードリンク管理データの作成，編集を行うことができる。これにより、設計支援システム１０に、機能ノードについての検討実績が蓄積されていく。

図７は、方式情報ＤＢ３５０が管理する方式情報データのデータ構成の一例を示す図である。ここで、方式情報データは、ある機能を下位の機能に細分化する際に、細分化する機能群が複数通り考えられる場合に、それぞれの機能群をまとめたものである。例えば、「着火する」という上位の機能に対して、「火打石を着火ローラに押しつける」および
「着火ローラを回転させる」という第１の機能群と、「電圧を発生させる」および「ワイヤで放電させる」という第２の機能群とに細分化できる場合に、第１の機能群は「摩擦着火方式」とまとめ、第２の機能群は「電子着火方式」とまとめることができる。すなわち、設計対象の装置の機能としていずれの方式を選択するかによって、細分化される機能が定まってくる。

本図において方式情報データは親機能３５０ａと、方式３５０ｂとを１レコードとして
管理する。方式３５０ｂは、さらに、方式ＩＤ，方式名，機能構造を管理して、親機能
３５０ａについての方式情報データを格納する。

方式情報データは、設計対象の装置対応に作成されている。ユーザは、例えば、方式情
報データをテンプレートして用いることで、機能モデルの作成・編集を効率的に行えるようになる。また、データ編集処理部１１０を利用して、方式情報データの作成，編集を行うこともできる。

図８は、不具合事例ＤＢ３６０が管理する方式情報データのデータ構成の一例を示す図である。本図に示すように、不具合事例ＤＢ３６０は、方式情報データの機能構造の機能対応に、不具合の事例を記録するデータベースである。

ユーザは、ある方式情報データの機能について不具合事例を取得した場合には、データ編集処理部１１０を利用して、不具合事例の登録を行うことができる。これにより、設計支援システム１０に、機能に対応した不具合事例が蓄積されていく。

履歴ＤＢ３７０は、設計支援システム１０における各種処理の履歴を記憶するデータベースである。

機能モデル生成部１２０は、機能ノードＤＢ３１０，部品ノード３２０およびノードリンク管理ＤＢ３３０を参照して、機能モデルを生成して、表示装置２１０に表示させることができる。

図９は、表示装置２１０に表示される機能モデル表示画面の一例を示す図である。機能モデル生成部１２０は、ノードリンク管理ＤＢ３３０のルート機能ノード３３０ａを参照
して、ルートとなる機能ノードを定める。そして、リンク３３０ｂにしたがって機能ノードＤＢ３１０および部品ノードＤＢ３２０からデータを抽出し、それぞれのノードを結ぶことで本図に示すような機能モデルを作成することができる。

本図の例では、ルートとなる機能ノードとして、ライターの主目的である「火を着ける」が抽出され、以下、機能ノードが４階層まで細分化され、最終的に「タンク」「ノズル」等の部品ノードにリンクしている。また、機能モデル表示画面には、「詳細表示」ボタ
ン，「一括表示」ボタン，「上位１段階表示」ボタン，「下位１段階表示」ボタン，コメント入力欄，「検討項目表示」ボタン，「方式表示」ボタン，「不具合事例登録」ボタン，「不具合事例検索」ボタン，「部品画像表示」ボタンが配置されている。

ユーザは、入力装置２２０を操作して、機能モデル表示画面上において、いずれかのノ
ードを選択した状態で、所望のボタンをクリックすることができる。設計支援システム
１０の検索処理部１３０等は、クリックされたボタンに応じて以下に示すような種々の処理を行う。ノードの選択は、例えば、希望のノードをポインティングしてクリックするこ
とで行うことができる。

ある機能ノードが選択された状態で「詳細表示」ボタンのクリックを受け付けると、検
索処理部１３０は、対応する機能ノードデータを機能ノードＤＢ３１０から抽出するとと
もに、検討実績ＤＢ３４０からその機能ノードについて行われた検討実績データを抽出し、抽出されたデータに基づく情報を機能詳細情報画面として表示装置２１０に表示する。

図１０は、機能ノードとして「ガスを放出する」が選択された状態で、「詳細表示」の
クリックを受け付けたときの機能詳細情報画面の一例を示す図である。本図に示すように
、「ガスを放出する」（機能ＩＤ：Ｆ１）をキーとして抽出された機能ノードデータおよ
び検討実績データに基づく情報が画面上に配置されている。

あるノードが選択された状態で「一括表示」ボタンのクリックを受け付けると、検索処
理部１３０は、ノードリンク管理ＤＢ３３０等を参照して、選択されているノードに直接
的および間接的にリンクされているノードを抽出し、抽出されたノードを強調した機能モ
デルを表示装置２１０に表示する。

ユーザである設計者は、設計対象の装置の設計変更等のために検討を行う際には、部品，機能の変更によって、どこまで影響が及ぶかを把握することが重要である。本設計支援システム１０では、機能モデル表示画面上で設計変更の対象となる部品あるいは機能のノードを選択し、「一括表示」ボタンをクリックすることで、影響を受ける機能，部品を網羅的に把握することができるようになる。

図１１は、部品ノードである「フード」が選択された状態で、「一括表示」ボタンのク
リックを受け付けた場合の機能モデルの表示例である。すなわち、「フード」と直接的に
リンクされている機能ノードである「風を防ぐ」「ローラを規制する」に加え、上位階層
で間接的にリンクされている機能ノードである「ガスを放出する」「着火ローラを回転さ
せる」「可燃物を置く」「着火する」「火を着ける」が強調されている。これらの機能ノ
ードが部品である「フード」を設計変更した場合に影響を受けることが示されている。

なお、選択されたノードが本図のように部品ノードの場合には、リンクは上位階層への
一方向であるが、機能ノードが選択されている場合には、上位，下位の両方向についてリ
ンクされているノードが抽出される。下位方向への検索を行うことで、例えば、ある機能ノードの機能性の変更に対して影響を受ける部品の洗い出し等を行うことができる。なお、下位方向の検索の場合も、検索処理部１３０は、ノードリンク管理ＤＢ３３０を参照することでリンクされているノードを抽出することができる。

「一括表示」ボタンがクリックされた場合には、直接的および間接的にリンクされているすべてのノードが一括的に表示されるが、「上位１段階表示」ボタンあるいは「下位１段階表示」ボタンがクリックされた場合には、検索処理部１３０は、上位または下位に１階層ずつリンクを辿り、クリックされる毎に上位または下位にリンクされているノードを強調表示する。

したがって、設計変更による影響を考慮する上で、必要ないと判断したノードについては検討の対象外とすることができる。必要な階層までの機能ノード等を抽出することにより作業の効率性を向上させることができる。

なお、途中で階層表示をやめる場合には、その理由についてコメント表示欄に入力して
おくことができる。制御装置１００は、コメント表示欄に入力されたコメントは、階層の
表示状態とともに履歴ＤＢ３７０に記録する。これにより、ユーザは、後から検討を中止
した理由を参照することが可能となる。

検索処理部１３０は、一括表示、あるいは、段階表示により抽出されたノードを別途リスト形式で表示することができる。また、抽出された機能ノードデータに含まれる検討項目３１０ｅだけを抜き出してリスト表示することができる。

機能モデル表示画面には、このための「検討項目表示」ボタンが配置されている。図
１２は、「検討項目表示」ボタンがクリックされた場合に表示される画面例を示しており、図１２（ａ）は、「一括表示」に対応する検討項目表示画面の例であり、図１２（ｂ）は、階層表示を途中でやめた場合に対応する検討項目表示画面の例を示している。

なお、ノードリンク管理データでは、下位層において機能ノードと部品ノードとを直接
的にリンクするようにしていたが、機能ノードと部品ノードの設計パラメータとをリンク
するようにしてもよい。図１３は、機能ノードと部品ノードの設計パラメータとをリンク
させるようにした場合の、機能モデル表示画面を示す図である。

本図の例では、部品ノードである「着火ローラ」には、設計パラメータとして「サイズ」「強度」「形状」が定義されている。このとき、設計パラメータの「サイズ」には機能ノードの「バネの上に置く」「ローラを規制する」が関連付けられているとする。

このような機能モデルにおいて、着火ローラのサイズに関する設計変更を行う場合には、設計パラメータの「サイズ」を選択した状態で「一括表示」ボタン等をクリックすればよい。この結果、図１４に示すように、「バネの上に置く」「ローラを規制する」等の機能ノードが強調表示され、着火ローラのサイズを変更した場合の影響が及ぶ範囲を確認することができる。

機能ノードと部品ノードとを直接的にリンクしていた場合には、「摩擦を受ける」「滑
り止めを設ける」等のサイズの変更では影響を受けない機能ノードまで抽出されることに
なるため、機能ノードと部品ノードの設計パラメータとをリンクすることにより、設計変
更の検討のための作業効率が向上することになる。

機能モデル表示画面上で、ある機能ノードが選択された状態で「不具合事例登録」ボタ
ンのクリックを受け付けると、データ編集処理部１１０は、不具合事例入力のための画面
を表示し、ユーザに不具合事例の入力を促す。そして、入力された不具合事例を選択され
ている機能ノードに関連付けて不具合事例ＤＢ３６０に記録する。

また、ある機能ノードが選択された状態で「不具合事例検索」ボタンのクリックを受け
付けると、検索処理部１３０は、不具合事例ＤＢ３６０を参照して、選択されている機能
ノードに関連付けられている不具合事例を抽出して表示装置２１０に表示する。これによ
り、機能検討段階で、ユーザは、機能ノードに関して過去の不具合事例を参照することが
できる。

また、リンクされている機能ノードについても関連付けられている不具合事例を抽出し
て表示するようにしてもよい。これにより、不具合事例を網羅的に抽出することができる
。

ここで、リンクされている機能ノードは、具体的には選択した機能ノードの下位のすべ
ての機能ノードを対象とすることが有効であるが。これにより、選択した機能に関連する
すべての不具合を抽出することが可能となる。

設計支援システム１０では、ある時点での機能モデルを履歴情報として履歴ＤＢ３７０
に記録しておくことができる。例えば、ある装置Ａに関して設計変更を行う際に、装置Ａを表わす機能モデルを記録しておく。そして、設計変更後の装置を装置Ｂとすると、装置Ａの機能モデルと、装置Ｂの機能モデルとを並べて表示装置２１０に表示させることで、どの機能ノードあるいは部品ノードが変更されたかを視覚的に確認することができるようになる。この際、両者の差分を検出し、変更部分を強調表示させるようにしてもよい。

機能モデル表示画面上で「部品画像表示」ボタンのクリックを受け付けると、検索処理
部１３０は、部品ノードＤＢ３２０のＣＡＤ情報３２０ｄを参照して、各部品から構成さ
れる装置の画像データを生成し、表示装置２１０に表示する。

図１５は、部品ノードＤＢ３２０のＣＡＤ情報３２０ｄに基づいて、設計対象の装置で
あるライターの画像が表示されている例を示している。ユーザは、本画面上で、装置を構
成する部品を選択することができる。

検索処理部１３０は、本画面上で部品の選択を受け付けると、ノードリンク管理ＤＢ
３３０を参照して、選択されている部品ノードに関連付けられている機能ノードを抽出し、画面上に表示する。図１６は、部品として着火ローラが選択された場合の表示例を示している。このようにすることで、装置の部品を視覚的に確認することができ、また、部品の設計変更により影響を受ける機能を確認することができるようになる。

また、機能モデル表示画面上で、機能ノードを選択した状態で「部品画像表示」ボタン
のクリックを受け付けると、検索処理部１３０は、ノードリンク管理ＤＢ３３０を参照し
て、選択されている機能ノードの下位機能ノードを抽出する。さらに、抽出した機能ノー
ド群に関連付けられている部品ノード群を抽出し、各部品に対するＣＡＤ情報３２０ｄを
部品ノードＤＢ３２０から取得して、画面上に表示する。これにより、選択した機能を実
現するに必要な部品を画面上で確認することができるようになる。

つぎに、機能モデルと連携して設計支援を行う機能検証モデルについて説明する。上述のように機能モデルでは、機能ノードおよび部品ノードについて階層的に関連付けを行うことで、機能ノードあるいは部品ノードの設計変更を行った場合に影響を受ける範囲の確認を行うことができ、設計変更の際の各機能等の検証を効率的に行うことができた。

機能検証モデルでは、機能ノードの目標仕様の項目（目標パラメータ），動作条件の項目（動作パラメータ）、および、部品ノードの設計パラメータについての関連付けを行う。つまり、機能検証モデルは、ある機能、例えば、「ガスを放出する」を検証対象としたとき、動作パラメータである「外気温」「風速」のある条件の下で、目標パラメータである「流量」のある値が得られることを検証する際の支援を行うもので、よりパラメータに注目した機能モデルである。

図１７に示すように、部品ノードの設計パラメータは、機能ノードの目標パラメータと関連付け、機能ノードの動作パラメータは、他の機能ノードの目標パラメータと関連付けられる。

この関連付けを容易に行えるように、データ編集処理部１１０は、図１８に示すように、機能ノードＤＢ３１０に記録されている機能ノードデータおよび部品ノードＤＢ３２０に記録されている部品ノードデータについて、ある設計パラメータあるいは目標パラメータに注目した際に、動作パラメータのリストを表示して、注目したパラメータと関連付けを行う動作パラメータの指示を受け付けるための画面を表示装置２１０に表示する。動作パラメータの指示は、例えば、本図に示すように、関連付けを行う動作パラメータ（動作条件）にマークを付すことで行うようにすることができる。なお、パラメータの関連付けは、一方向ではなく、関連付けられたパラメータ同士は双方向に関連付けが行われているものとする。パラメータの関連の付けのための情報は、例えば、パラメータリンク管理
ＤＢ（図示せず）として記憶装置３００上に構成したデータベースに記録することができる。

パラメータリンク管理ＤＢでは、例えば、関連付けられたパラメータ同士を１組として
記録することで、パラメータの関連の付けのための情報を管理することができる。

この関連付けの結果、図１９に示すように、機能モデルとは別に、機能検証モデルが作成される。機能モデルにおける各ノードと機能検証モデルにおける各ノード（機能検証ノ
ード）とは、１対１に対応するが、ノードを結びつけるリンク情報が異なっている。すなわち、機能モデルではノード単位でリンクされているが、機能検証モデルではノードに含まれるパラメータ単位でリンクされている。

つぎに、機能検証モデルを用いた機能検証処理について、図２０のフロー図および図
２１を参照して説明する。

設計支援システム１０は、ユーザから設計変更対象のパラメータの指定を受け付ける
（Ｓ１０１）。図２１の例では、部品１の設計パラメータ１が指定されたものとする。ここで、設計パラメータ１は、例えば、部品１のサイズ等とすることができる。この場合、本例では、部品１のサイズを変更した場合に、影響を受け、検証が必要となる機能検証ノードおよび他のパラメータの抽出を行うことになる。

検索処理部１３０は、機能検証モデルに基づいて、指定を受けたパラメータに関連付けられているパラメータおよびそのパラメータを有する機能検証ノードを検索する（S102)。

その結果、パラメータ等が抽出された場合には（Ｓ１０３：Ｙ）、抽出されたパラメー
タをユーザに提示して、影響を受けるため検証が必要であることを通知する（Ｓ１０４）。図２１の例では、機能２の動作パラメータ３が表示される。

また、抽出された機能検証ノード、および、その機能検証ノードに含まれるパラメータを表示して、さらに検証を行うかどうかの指示を受け付ける（Ｓ１０５）。図２１の例では、抽出された機能検証ノードとして機能２が表示され、パラメータとして動作パラメータ３，動作パラメータ４，目標パラメータ２，目標パラメータ３が表示される。

さらに検証を行うかどうかの指示の受け付けは、抽出されたそれぞれのパラメータについて変更するかしないかの指示をユーザから受け付けることで行う。すなわち、図２１の例では、動作パラメータ３，動作パラメータ４，目標パラメータ２，目標パラメータ３のそれぞれについて、変更を行うか行わないかの指示をユーザから受け付けることになる。もちろん、変更を行うパラメータ、あるいは、変更を行わないパラメータの一方の指示を受け付けるようにしてもよい。

このため、設計支援システム１０は、図２２に示すような、それぞれのパラメータについて変更を行うかどうかを指示するためのチェックボックス等を備えた画面を表示装置
２１０に表示する。

ここでは、目標パラメータ３および動作パラメータ３とが変更するパラメータとして指定されたものとする。

検索処理部１３０は、変更すると指定されたパラメータのそれぞれについて、さらに、関連付けられているパラメータおよびそのパラメータを有する機能検証ノードを検索する処理を行う（Ｓ１０２）。

なお、変更しないと指定されたパラメータに関連付けられているパラメータは、検索対象から外すようにする。図２１の例では、変更しないと指定された目標パラメータ３に関連付けられている機能３の動作パラメータ５、および、動作パラメータ４に関連付けられている部品２の設定パラメータ３は検索対象から外される。ただし、変更しないパラメータとして抽出するようにしてもよい。

検索処理の結果、新たなパラメータおよび機能検証ノードが抽出されない場合には
（Ｓ１０３：Ｎ）、最初に指示を受けたパラメータの設計変更により影響を受ける、すなわち、検証対象とすべき機能検証ノードをすべて抽出したとして検索処理を終了する。

そして、設計支援システム１０は、抽出された機能検証ノード、抽出されたパラメータ
のリストを作成する。このリストは、画面上に表示することができる。このとき、抽出さ
れたパラメータについては、変更対象となったパラメータと変更しないパラメータとを区
別してリスト表示するものとする。また、機能ノードデータに記憶されている検討項目
３１０ｅも含めるようにする。これにより、変更するパラメータに影響を受け、検討すべき項目を網羅的に把握することができるようになる。このリストは、例えば、検討項目リストとして記憶装置３００に格納する。

設計担当者であるユーザは、このリストを印刷した表を、検証作業者等に渡すことで、
設計変更に伴う検討項目を漏れなく伝えることができる。

機能検証モデルを用いた機能検証処理は、ユーザに機能検証モデルを意識させないような画面上で行うようにすることもできる。図２３は、機能検証処理を行うための画面の別例を示す図である。

ユーザは、本図に示すウインドウ３００１を利用し、設計変更の影響探索を行うことができる。符号３００２は影響探索を行う初めのパラメータを示している。これにより、この設計変更の最初のきっかけを明示することができる。符号３００３は、機能モデルと、検討項目リストの表示エリアである。本図では機能モデルが表示されているが、検討項目リストは、図２４の画面３１０１に示すような表示になる。なお、この検討項目リストは、上記説明の機能検証モデル、機能データノードに１対１に対応している。機能モデルと検討項目リストの両表示は、符号３００３で示すエリアの上部にあるタブにより切り替え可能である。

符号３００４は、設計対象の装置を構成する部品の一覧をリスト表示する部品リスト欄である。部品リスト欄３００４から変更したい部品を選択、または、機能モデル３００３あるいは検討項目リスト３１０１から、検証したい項目、つまり、機能データを選択すると、その内容が符号３００５で示す領域に表示される。

符号３００５は、機能データおよび機能検証モデルの内容を表示する領域を示している。ここでは、機能名，機能の説明，検証のためのパラメータと入出力の区別，変更する，しないの指定，検証方法などが表示，設定できるようになっている。ここで、入力パラメータは動作パラメータに対応し、出力パラメータは目標パラメータに対応する。また、変更の検証を行う場合の重要度とその理由を設定できるようになっている。さらに、領域
３００５には、パラメータを変更する、しない等の事項を入力した後に、探索を指示するための「一段階検索」ボタンが配置されている。

「一段階検索」ボタンで探索を指示したことによる結果は、符号３００６で示す領域に
表示される。この領域は、「一段階検索」で探索指示した１回分の機能検証モデルの検索
結果を表示するものである。ユーザは、この領域で、検索結果を確認後、領域３００６に
配置された検討項目に追加を指示する「検討項目に追加」ボタンをクリックすることがで
きる。このボタンのクリックにより、各項目である機能検証モデル（検討項目）が、機能
モデル３００３および、検討項目リスト３１０１に反映される。

各機能検証モデルは、検索されたかどうか、また、検索後に変更影響を検討したかどう
かの状態を保持し、その状態を領域３００３や領域３１０１，領域３００６に項目として
表示する際に明示する。ユーザは、すべての検索済み機能検証モデルに対して、変更影響
を検討するまで領域３００３，領域３１０１での機能選択，変更パラメータの指示，影響
の検索を繰り返すことができる。

すべての検索が終了した時点で、領域３００８に設けられた「保存」ボタンで検討項目
を保存することができる。また、途中で作業を終了し、後で続けることができるように、
現在の検索状態を格納することができるボタンも配置されている。

「保存」ボタンにより格納された検討項目リストの例を図２５に示す。検討項目リスト
では、まず、変更目的として変更のきっかけとなった部品とそのパラメータが格納される
。そして、検討項目ごとに、検証内容，変更パラメータ，変更しないパラメータ，検証の
重要度，理由が格納される。

このようなユーザインタフェースを採用することにより、機能検証モデルネットワークや、機能モデルが大規模になっても画面が煩雑にならずに影響の検索を確実に行うことが
可能となる。

本発明の別の実施形態について説明する。

図２６は本実施形態の設計支援システム１１の構成を示すブロック図の一例である。本図は図１に加えて、検索方法判断部２６０１と表示順序決定部２６０２のブロック，パラメータリンクＤＢ２６０３が追加されている。内部には機能モデルと機能検証モデルが構成されている。

また、本実施例では機能検証モデルにおいて、機能ノードおよび部品ノードに属するパラメータについて、必要に応じてフラグをたてることができる。このフラグには、「性能パラメータ」「直接変更パラメータ」がある。

「性能パラメータ」はそのパラメータの値が製品の外部仕様（性能）を表す値であることを表す。ライターを例に取れば、「連続使用時間」といったパラメータである。「直接変更パラメータ」は値が、製品を構成する個々の部品に関連した具体的な値であることを表す。ライターを例にとれば、「タンク」の寸法や、「火打石」と「着火ローラ」の摩擦係数、「バネ」のバネ定数などをあらわす。

設計作業において、設計者が「性能パラメータ」を直接変更できることは少ない。設計者が直接変更することができるのは「直接変更パラメータ」であり、これらをいろいろに変更して所定の性能を満たすようにする。

また、「性能パラメータ」には、重要度がつけられるようになっている。製品の利用者からみたとき、大事な性能とそれほどでも無い性能がある。たとえば、ライターの場合、一般には着火の成功率は連続使用時間よりも大事であろう。もちろん、利用者の好みや利用状況により変わるが、重要度とは、この大事さの度合いを数字としてあらわすものである。パラメータにフラグと重要度を設定した様子を図２７に示す。

このフラグおよび重要度の設定は機能モデル生成部１２０で変更することができる。設計支援システム１１における検索処理についてフロー図２８を用いて説明する。本実施例においては、検索の起点になるのは、必ずフラグのついたパラメータである。

設計者は設計の変更をパラメータの変化として入力する（ステップ２８０１）。さらに、設計者は検索結果を絞り込む理由で、検索深さＤｓを入力する（ステップ２８０２）。このステップは任意である。もし、検索結果を絞り込む必要がないのであれば検索深さは設定する必要はない。

検索方法判断部２６０１はパラメータにつけられたフラグをみて検索処理方法を判断する（ステップ２８０３）。

パラメータの種類が「性能パラメータ」だった場合はステップ２８０４に進む。「直接変更パラメータ」だった場合はステップ２８０６に進む。

ステップ２８０４では、性能実現手段検索処理を実施する。この検索処理は、性能パラメータの変更を実現するためには、どの機能ノードを検討しなければならないかを検索する処理である。この処理について図２９を用いて説明する。

まず、パラメータが機能ノードに属するかどうかを判断する（ステップ２９０１）。機能ノードに属する場合はステップ２９０２に進む。部品ノードに属する場合はステップ
２９０７に進む。また、距離カウンタＤｃを０に設定する。

ステップ２９０２では、パラメータが目標仕様パラメータか動作条件パラメータかを判断する。パラメータが目標仕様パラメータだった場合は、そのパラメータが属するノードを検索結果として追加する（ステップ２９０３）。さらに、その機能ノードに属する動作条件パラメータを抽出し（ステップ２９０４）、それぞれについてステップ２９０５を実施する。ステップ２９０２で、パラメータが動作条件パラメータだった場合は、直接ステップ２９０５に進む。ステップ２９０５では、動作条件パラメータに関連するパラメータを抽出し、距離カウンタＤｃに１を足す。ステップ５０６では、検索深さＤｓが設定されていれば、距離カウンタＤｃと検索深さＤｓを比較する。ＤｃがＤｓ以下であるか、または、Ｄｓが設定されていない場合は、それぞれのパラメータについてステップ２９０１へ戻って処理を続ける。ＤｃがＤｓよりも大きければ、処理を終了する。

ステップ２９０７では、部品ノードを検索結果へ追加し、処理を終了する。上記検索処理における検索距離の考え方は、同じノード内にあるパラメータの距離は数えない。連結したパラメータとパラメータに張られたリンクの間を距離１として数えている。対象とするパラメータ間に複数のルートがある場合は、もっとも少ない距離のルートを採用する。

ステップ２８０４が終わると、表示順序決定部２６０２において、検索結果の表示画面の作成を行う（ステップ２８０５）。

本システムでは検索結果は、機能ノードまたは部品ノードのリストとして表示されるが、この表示順序を機能検証モデルに設定された重要度にもとづいて決定する。

表示順序は、ノードに含まれるパラメータに重要度が付与されているものを先に表示する。それらのノードの間では、付与された重要度が高い順に表示し、ノードに重要度を付与されたパラメータが複数あれば、もっとも重要度の大きいものを用いて判断する。重要度が同点であれば、２番目に大きな重要度を用いる。重要度が付与されていないノードについては、もっとも大きい重要度をもつパラメータからの距離を用いて判断する。さらに、同順位となる場合は、順序については関知せず、順不同とする。ここでの距離は、検索処理時の距離カウンタＤｃと同様の考え方で測る。ここでも、もっとも大きい重要度からの距離が同じであれば、２番目に大きな重要度からの距離を用いる。

たとえば、図３０のライターの機能モデル，機能検証モデルを例に取ると、ライターの「連続使用時間」というパラメータが「性能パラメータ」であり、このパラメータの値が「２時間」から「５時間」に変更されたとする。また検索距離は２を指定したとする。この場合、出力は図３１のようになる。

このように表示することによって、性能パラメータの変更によって影響を受ける検証項目を重要度順に知ることができる。

また、検索深さを設定せず、検索結果を部品ノードに絞ってもよい。この場合は、「性能パラメータ」の変更を満たすために、検討が必要な部品が検索されることになる。また、ステップ２８０２における検索深さの設定も必要ない。設計者の多くは、部品を中心に製品設計を考えているため、この方法は設計者の感覚に沿うものである。この場合、出力は図３２のようになる。

上記、検索深さは、パラメータリンクに基づいて測ったが、機能モデル上の階層数を用いてもよい。図３０を例にとると「可燃物を置く」と「風を防ぐ」の間の距離は２である。

ステップ２８０６では、影響範囲限定検索を実施する。この検索処理は、直接変更パラメータの変更による、影響を最小限にとどめるためには、どの機能ノードを検討しなければならないかを検索する処理である。

検索元のパラメータから、設定された検索深さ分だけ上位へたどる。このとき、パラメータ間の距離の考え方はステップ２８０４の説明で述べたときと同じである。すなわち、パラメータ間のリンクを距離１として、最短のルートを用いて距離を定義する。

具体的には、図３３に示す手順によって処理する。

まず、パラメータが機能ノードに属するかどうかを判断する（ステップ３３０１）。機能ノードに属する場合はステップ３３０２に進む。部品ノードに属する場合はステップ
３３０７に進む。また、距離カウンタＤｃを０に設定する。

ステップ３３０７では、部品ノードを検索結果へ追加し、そのパラメータに関連する機能ノードのパラメータを抽出し、ステップ３３０２にすすむ。

ステップ３３０２では、パラメータが目標仕様パラメータか動作条件パラメータかを判断する。パラメータが動作条件パラメータだった場合は、そのパラメータを中間検索結果として追加する（ステップ３３０３）。さらに、そのパラメータが属する機能ノードに属する目標仕様パラメータを抽出し（ステップ３３０４）、それぞれについてステップ3305を実施する。ステップ３３０２で、パラメータが目標仕様パラメータだった場合は、直接ステップ３３０５に進む。ステップ３３０５では、動作条件パラメータに関連するパラメータを抽出し、距離カウンタＤｃに１を足す。ステップ８０６では、検索深さＤｓが設定されていれば、距離カウンタＤｃと検索深さＤｓを比較する。ＤｃがＤｓ以下であるか、それぞれのパラメータについてステップ３３０１へ戻って処理を続ける。ＤｃがＤｓよりも大きければ、処理を終了する。または、Ｄｓが設定されていない場合は、デフォルトの検索深さとして１を使う。ただし、このデフォルト値は処理を始める前に決めればよく、他の値でもよい。

次に、中間検索結果パラメータから図２９に示す処理で、検索結果を得る。ステップ
２８０６が終わると、表示順序決定部２６０２において、検索結果の表示画面の作成を行う（ステップ２８０７）。影響範囲限定検索では、検索元のパラメータからの距離によって検索結果を表示する。

たとえば、図３０のライターの機能モデル，機能検証モデルを例に取ると、部品「フード」の「形状」が変更されたとする。また検索距離は２を指定したとする。この場合、出力は図３４のようになる。

この検索処理によって、設計者は変更の影響をなるべく限定した部分で完結する方向で作業できる。

また、検索結果を部品ノードに限定しても良い。この場合の出力は図３５のようになる。これは、影響はねかえり部品を検索していることになる。

上記、検索方法では、事前にパラメータの種類「性能パラメータ」「直接変更パラメータ」を設定したが、機能モデル上の木構造のルートからＬ１までの機能ノードに含まれるパラメータを「性能パラメータ」、木構造のルートからＬ２より下位の機能ノードに含まれるパラメータと部品ノードに含まれるパラメータを「直接変更パラメータ」と定義しても良い。このときＬ１はＬ２より小さくなければならない。

もしくは、「直接変更パラメータ」は部品ノードに含まれるパラメータ、それ以外は
「性能パラメータ」としてもよい。通常、部品の寸法，物性は設計者が直接変更できるので、実用的でもある。

この方法によれば予めパラメータ種類を設定する手間を大幅に省くことができる。

上記、機能モデル，機能検証モデルでは、製品を構成する部品のみを部品ノードとして扱った。しかし、製品を動作させるのに必要な燃料や、エネルギー、組立時に用いる接着剤なども部品ノードとして扱うことができる。たとえば、ライターにおいては「ガス」という部品ノードを使っても良い。また、製品の利用環境についても、ひとつの部品ノードとして扱っても良い。たとえば、ライターにおいては「外部環境」という部品ノードを作成し、その中で「気温」「湿度」など利用されるときの環境値をいれることができる。

こうすることで、製品が実際に利用される場面を想定した機能モデル，機能検証モデルが作成でき、より不具合の少ない設計が可能になる。

設計支援システム１０の構成の一例を示すブロック図である。 機能モデルを説明するための図である。 機能ノードＤＢ３１０が管理する機能ノードデータのデータ構成の一例を示す図である。 部品ノードＤＢ３２０が管理する部品ノードデータのデータ構成の一例を示す図である。 ノードリンク管理ＤＢ３３０が管理するノードリンク管理データのデータ構成の一例を示す図である。 検討実績ＤＢ３４０が管理する検討実績データのデータ構成の一例を示す図である。 方式情報ＤＢ３５０が管理する方式情報データのデータ構成の一例を示す図である。 不具合事例ＤＢ３６０が管理する方式情報データのデータ構成の一例を示す図である。 表示装置２１０に表示される機能モデル表示画面の一例を示す図である。 機能ノードとして「ガスを放出する」が選択された状態で、「詳細表示」のクリックを受け付けたときの機能詳細情報画面の一例を示す図である。 部品ノードである「フード」が選択された状態で、「一括表示」ボタンのクリックを受け付けた場合の機能モデルの表示例である。 「検討項目表示」ボタンがクリックされた場合に表示される画面例を示す図である。 機能ノードと部品ノードの設計パラメータとをリンクさせるようにした場合の、機能モデル表示画面を示す図である。 機能ノードと部品ノードの設計パラメータとをリンクさせるようにした場合の、機能モデル表示画面を示す図である。 設計対象の装置であるライターの画像が表示されている例を示す図である。 部品として着火ローラが選択された場合の表示例を示す図である。 機能検証モデルを説明するための図である。 関連付けを行う動作パラメータの指示を受け付けるための画面を示す図である。 機能検証モデルの一例を示す図である。 機能検証モデルを用いた機能検証処理について説明するためのフロー図である。 機能検証モデルを用いた機能検証処理について説明するための図である。 パラメータについて変更を行うかどうかを指示するための画面を示す図である。 機能検証処理を行うための画面の別例を示す図である。 検討項目リストを表示する画面を示す図である。 格納された検討項目リストの例を示す図である。 設計支援システム１１の構成の一例を示すブロック図である。 設計パラメータに付与するフラグを説明する図である。 設計変更の種類によって検索処理，表示方法を変更するフロー図である。 性能実現手段検索処理のフロー図である。 機能検証モデルの一例を示す別の図である。 性能実現手段検索処理の出力の図である。 性能実現手段検索処理の別の出力の図である。 影響範囲限定検索処理のフロー図である。 影響範囲限定検索処理の出力の図である。 影響範囲限定検索処理の別の出力の図である。

符号の説明

１０…設計支援システム、１００…制御装置、１１０…データ編集処理部、１２０…機能モデル生成部、１３０…検索処理部、２１０…表示装置、２２０…入力装置、３００…記憶装置、３１０…機能ノードＤＢ、３２０…部品ノードＤＢ、３３０…ノードリンク管理ＤＢ、３４０…検討実績ＤＢ、３５０…方式情報ＤＢ、３６０…不具合事例ＤＢ、370…履歴ＤＢ。

Claims (29)

1. 設計対象の装置が果たすべき機能を上位の機能から下位の機能へと細分化した機能を表すノードからなる機能ノード群とある機能を実現するための部品を表す部品ノードからなる部品ノード群とを有するノードデータを格納するノードデータ格納手段と、
   前記ノードデータ格納手段を参照して、上位の機能と下位の機能又は部品とを関連付けて階層化した機能モデルを生成する機能モデル生成手段と、
   前記機能モデルの中から、ノードの指定を受け付けるノード指定受付手段と、
   前記指定されたノードが部品ノードの場合には、上位階層方向へ関連付けられた機能ノードを、前記指定されたノードが機能ノードの場合には、上位階層及び下位階層方向へ関連付けられた機能ノード又は部品ノードを、抽出するノード抽出手段と、
   抽出されたノードを提示する抽出ノード提示手段を備えた
   設計支援システムであって、
   前記部品ノードは、それぞれ１または複数の設計に関するパラメータを有しており、
   前記機能ノードは、それぞれ、１または複数の動作に関するパラメータおよび目標に関するパラメータを有しており、
   パラメータ同士の組み合わせを規定したパラメータ関連情報を格納するパラメータ関連情報格納手段と、
   前記パラメータ関連情報格納手段を参照して、ノードに含まれるパラメータ同士の関係を示す機能検証モデルを生成する機能検証モデル生成手段と、
   前記機能検証モデルの中から、パラメータの指定を受け付けるパラメータ指定受付手段と、
   前記指定を受け付けたパラメータについて、関連付けられたパラメータを抽出するパラメータ抽出手段とを備えるものにおいて、
   前記受け付けたパラメータ指定が外部仕様の変更に関するものである場合は、前記パラメータ抽出手段によって抽出されたパラメータを仕様の重要度の順に出力する出力手段を有する
   ことを特徴とする設計支援システム。
2. 請求項１に記載の設計支援システムにおいて、
   前記機能ノードは、その機能についての検討項目データを含み、
   前記抽出ノード提示手段は、抽出された機能ノードについて、含まれる検討項目データの一覧を提示することを特徴とする設計支援システム。
3. 請求項１に記載の設計支援システムにおいて、
   前記ノード抽出手段は、階層関係を有するノードの一括抽出と、階層毎の抽出とを選択的に行うことを特徴とする設計支援システム。
4. 請求項１に記載の設計支援システムにおいて、
   前記機能ノードに関連付ける検討実績データを格納する検討実績データ格納手段と、指定を受けたノードについて、関連付けられている検討実績データを抽出する検討実績データ抽出手段と、抽出された検討実績データを提示する検討実績データ提示手段をさらに備えることを特徴とする設計支援システム。
5. 請求項１に記載の設計支援システムにおいて、
   前記機能ノードに関連付ける不具合事例データを格納する不具合事例データ格納手段と、
   指定を受けたノードについて、関連付けられている不具合事例データを抽出する不具合事例データ抽出手段と、
   抽出された不具合事例データを提示する不具合事例データ提示手段をさらに備えることを特徴とする設計支援システム。
6. 請求項５に記載の設計支援システムにおいて、
   前記不具合事例データ抽出手段は、さらに、指定を受けたノードの下位のノードについて、関連付けられている不具合事例データを抽出することを特徴とする設計支援システム。
7. 請求項１に記載の設計支援システムにおいて、
   前記部品ノードは、それぞれ１または複数の設計に関するパラメータを有しており、部品ノードと機能ノードとの階層構造は、設計に関するパラメータを介して構成されることを特徴とする設計支援システム。
8. 請求項１に記載のものにおいて、
   前記抽出されたパラメータを表示するパラメータ表示手段を有する
   ことを特徴とする設計支援システム。
9. 設計対象の装置が果たすべき機能を上位の機能から下位の機能へと細分化した機能を表すノードからなる機能ノード群とある機能を実現するための部品を表す備品ノードからなる部品ノード群とを有するノードデータを格納するノードデータ格納手段と、
   前記ノードデータ格納手段を参照して、上位の機能と下位の機能又は部品とを関連付けて階層化した機能モデルを生成する機能モデル生成手段と、
   前記機能モデルの中から、ノードの指定を受け付けるノード指定受付手段と、
   前記指定されたノードが部品ノードの場合には、上位階層方向へ関連付けられた機能ノードを、前記指定されたノードが機能ノードの場合には、上位階層及び下位階層方向へ関連付けられた機能ノード又は部品ノードを、抽出するノード抽出手段と、
   抽出されたノードを提示する抽出ノード提示手段を備えた
   設計支援システムであって、
   前記部品ノードは、それぞれ１または複数の設計に関するパラメータを有しており、
   前記機能ノードは、それぞれ、１または複数の動作に関するパラメータおよび目標に関するパラメータを有しており、
   パラメータ同士の組み合わせを規定したパラメータ関連情報を格納するパラメータ関連情報格納手段と、
   前記パラメータ関連情報格納手段を参照して、ノードに含まれるパラメータ同士の関係を示す機能検証モデルを生成する機能検証モデル生成手段と、
   前記機能検証モデルの中から、パラメータの指定を受け付けるパラメータ指定受付手段と、
   前記指定を受け付けたパラメータについて、関連付けられたパラメータを抽出するパラメータ抽出手段とを備えるものにおいて、
   前記受け付けたパラメータ指定が構成部品の仕様変更に関するものである場合は、前記パラメータ抽出手段によって抽出されたパラメータを影響の及ぶ度合いに応じて出力する出力手段を有する
   ことを特徴とする設計支援システム。
10. 請求項９に記載の設計支援システムにおいて、
    前記機能ノードは、その機能についての検討項目データを含み、
    前記抽出ノード提示手段は、抽出された機能ノードについて、含まれる検討項目データの一覧を提示することを特徴とする設計支援システム。
11. 請求項９に記載の設計支援システムにおいて、
    前記ノード抽出手段は、階層関係を有するノードの一括抽出と、階層毎の抽出とを選択的に行うことを特徴とする設計支援システム。
12. 請求項９に記載の設計支援システムにおいて、
    前記機能ノードに関連付ける検討実績データを格納する検討実績データ格納手段と、指定を受けたノードについて、関連付けられている検討実績データを抽出する検討実績データ抽出手段と、抽出された検討実績データを提示する検討実績データ提示手段をさらに備えることを特徴とする設計支援システム。
13. 請求項９に記載の設計支援システムにおいて、
    前記機能ノードに関連付ける不具合事例データを格納する不具合事例データ格納手段と、
    指定を受けたノードについて、関連付けられている不具合事例データを抽出する不具合事例データ抽出手段と、
    抽出された不具合事例データを提示する不具合事例データ提示手段をさらに備えることを特徴とする設計支援システム。
14. 請求項１３に記載の設計支援システムにおいて、
    前記不具合事例データ抽出手段は、さらに、指定を受けたノードの下位のノードについて、関連付けられている不具合事例データを抽出することを特徴とする設計支援システム。
15. 請求項９に記載の設計支援システムにおいて、
    前記部品ノードは、それぞれ１または複数の設計に関するパラメータを有しており、部品ノードと機能ノードとの階層構造は、設計に関するパラメータを介して構成されることを特徴とする設計支援システム。
16. 請求項９に記載のものにおいて、
    前記抽出されたパラメータを表示するパラメータ表示手段を有する
    ことを特徴とする設計支援システム。
17. 設計対象の装置が果たすべき機能を上位の機能から下位の機能へと細分化した機能を表すノードからなる機能ノード群とある機能を実現するための部品を表す備品ノードからなる部品ノード群とを有するノードデータを格納するノードデータ格納手段と、
    前記ノードデータ格納手段を参照して、上位の機能と下位の機能又は部品とを関連付けて階層化した機能モデルを生成する機能モデル生成手段と、
    前記機能モデルの中から、ノードの指定を受け付けるノード指定受付手段と、
    前記指定されたノードが部品ノードの場合には、上位階層方向へ関連付けられた機能ノードを、前記指定されたノードが機能ノードの場合には、上位階層及び下位階層方向へ関連付けられた機能ノード又は部品ノードを、抽出するノード抽出手段と、
    抽出されたノードを提示する抽出ノード提示手段を備えた
    設計支援システムであって、
    前記部品ノードは、それぞれ１または複数の設計に関するパラメータを有しており、
    前記機能ノードは、それぞれ、１または複数の動作に関するパラメータおよび目標に関するパラメータを有しており、
    パラメータ同士の組み合わせを規定したパラメータ関連情報を格納するパラメータ関連情報格納手段と、
    前記パラメータ関連情報格納手段を参照して、ノードに含まれるパラメータ同士の関係を示す機能検証モデルを生成する機能検証モデル生成手段と、
    前記機能検証モデルの中から、パラメータの指定を受け付けるパラメータ指定受付手段と、
    前記指定を受け付けたパラメータについて、関連付けられたパラメータを抽出するパラメータ抽出手段と、
    前記抽出されたパラメータを表示するパラメータ表示手段とを備えるものにおいて、
    前記受け付けたパラメータ指定にもとづいて設計対象の外部仕様の変更か構成部品の仕様変更かに応じて検索種類を選択する検索種類判定部と、
    当該検索種類判定部によって判定された検索種類に応じて検索結果の表示方法を変える表示画面処理部とを有し、
    当該表示画面処理部は、前記検索種類が外部仕様の変更である場合は、前記パラメータ抽出手段によって抽出されたパラメータを仕様の重要度の順に前記パラメータ表示手段に表示し、
    前記検索種類が構成部品の仕様変更である場合は、前記パラメータ抽出手段によって抽出されたパラメータを影響の及ぶ度合いに応じて前記パラメータ表示手段に表示するように切り替える
    ことを特徴とする設計支援システム。
18. 請求項１７に記載の設計支援システムにおいて、
    前記機能ノードは、その機能についての検討項目データを含み、
    前記抽出ノード提示手段は、抽出された機能ノードについて、含まれる検討項目データの一覧を提示することを特徴とする設計支援システム。
19. 請求項１７に記載の設計支援システムにおいて、
    前記ノード抽出手段は、階層関係を有するノードの一括抽出と、階層毎の抽出とを選択的に行うことを特徴とする設計支援システム。
20. 請求項１７に記載の設計支援システムにおいて、
    前記機能ノードに関連付ける検討実績データを格納する検討実績データ格納手段と、指定を受けたノードについて、関連付けられている検討実績データを抽出する検討実績データ抽出手段と、抽出された検討実績データを提示する検討実績データ提示手段をさらに備えることを特徴とする設計支援システム。
21. 請求項１７に記載の設計支援システムにおいて、
    前記機能ノードに関連付ける不具合事例データを格納する不具合事例データ格納手段と、
    指定を受けたノードについて、関連付けられている不具合事例データを抽出する不具合事例データ抽出手段と、
    抽出された不具合事例データを提示する不具合事例データ提示手段をさらに備えることを特徴とする設計支援システム。
22. 請求項２１に記載の設計支援システムにおいて、
    前記不具合事例データ抽出手段は、さらに、指定を受けたノードの下位のノードについて、関連付けられている不具合事例データを抽出することを特徴とする設計支援システム。
23. 請求項１７に記載の設計支援システムにおいて、
    前記部品ノードは、それぞれ１または複数の設計に関するパラメータを有しており、部品ノードと機能ノードとの階層構造は、設計に関するパラメータを介して構成されることを特徴とする設計支援システム。
24. 請求項８，１６および１７のいずれかに記載の設計支援システムにおいて、
    前記パラメータ表示手段は、抽出されたパラメータを含むノードをさらに表示することを特徴とする設計支援システム。
25. 請求項８，１６および１７のいずれかに記載の設計支援システムにおいて、
    表示されたパラメータについて、さらに関連付けられたパラメータを検索するかどうかの指示を受け付ける検索指示受付手段をさらに備え、
    前記パラメータ抽出手段は、さらに関連付けられたパラメータを検索すると指示されたパラメータについて、関連付けられたパラメータを抽出し、
    前記パラメータ表示手段は、当該抽出されたパラメータをさらに表示することを特徴とする設計支援システム。
26. 請求項２５に記載の設計支援システムにおいて、
    前記機能ノードは、その機能についての検討項目データを含み、前記パラメータ表示手段は、抽出されたパラメータを含む機能ノードについて、含まれる検討項目データの一覧を提示することを特徴とする設計支援システム。
27. 請求項２５に記載の設計支援システムにおいて、
    前記パラメータ抽出手段は、さらに関連付けられたパラメータを検索しないと指示されたパラメータに関連付けられているパラメータについては、抽出対象としないことを特徴とする設計支援システム。
28. 請求項１７に記載の設計支援システムにおいて、
    検索結果を部品ノードのみに絞り込む
    ことを特徴とする設計支援システム。
29. 請求項１，９および１７のいずれかに記載の設計支援システムにおいて、
    製品の利用環境や副資材をも部品ノードとして扱うことができる設計支援システム。

Images