JP2014146338A - 制御機器開発における製品バリエーションをデータ管理するためのコンピュータ実装される方法 - Google Patents

Abstract

【課題】御機器開発における製品バリエーションのデータ管理と関連した問題を解決する、コンピュータに実装される技術的なソリューションを提供すること
【解決手段】まずは、バリエーションモデルにおいて製品特徴を設定し、少なくとも１つの専門領域において構成要素を設定し、構成要素を少なくとも１つの製品特徴に割り当てることによって、特徴と構成要素の依存性を規定し、次に、製品特徴を選択することによって、興味を抱いている、少なくとも１つの製品バリエーションを設定し、興味を抱いている、少なくとも１つの専門領域を設定し、興味を抱いている、製品バリエーションに属している構成要素を、特徴と構成要素の依存性を自動的に評価することによって自動的に求め、求められた構成要素を自動的に出力する、コンピュータ実装される方法
【選択図】図４

Description

本発明は、制御機器開発における製品バリエーションをデータ管理するためのコンピュータ実装される方法に関する。

製品バリエーションをデータ管理するための方法は、技術的な開発の極めて様々な領域から既知であり、殊に、その開発時に例えば、様々な要求に製品を合わせることが必要となる技術的な製品において使用される。製品バリエーションの開発時のデータ管理の複雑なタスクを以降において、制御機器開発の分野に対して示す。

制御機器とは今日では、通常、産業上の使用のために準備された頑強な小型計算機のことである。これは主に、組み込まれたＩ／Ｏインタフェースを介して使用される。しばしば、リアルタイム動作システムが具備されている制御機器上では、次のようなプログラムが実行される。すなわち、広義において、Ｉ／Ｏインタフェースを介して、制御されるべき技術的なプロセスと関係を有し、このプロセスに所期のように作用するプログラムである。上述した種類の制御機器は、例えば集中的に自動車分野で使用される。制御機器の開発は、大量生産車の開発における重要な要素となっている。

制御機器開発は、以降で専門領域（ドメイン：Domaenen）と称される種々の領域に、テーマによって分けられる。ここでこれらの専門領域は種々の構成要素を有することができる。制御機器開発において、１つの専門領域は例えば要求仕様の専門領域であり、これは構成要素として、種々の要求仕様を伴う。別の専門領域は、種々の要求をテストするためのテストケースの専門領域、例えばハードウェア・イン・ザ・ループ・テストシステムのハードウェア記述の形式の、テストシステム記述の専門領域、制御機器環境をシミュレートするための数学モデルの専門領域またはモデルをパラメーター化するためのパラメーターセットの専門領域であり得る；この列挙は例示的なものであり、任意に拡張可能である。

複雑な製品を開発する際に、通常は、種々の製品バリエーションが生じる。これらの製品バリエーションは、特定の製品特徴において相違している。全製品特徴が集まって、全体として、バリエーションモデルが形成される。違いが著しい製品特徴は、カテゴリーに分けられる。これらは以降で、特徴カテゴリーと称される。製品特徴をこのようにカテゴリー化することによって、製品の特徴を概括しやすくなるが、これは、本願発明には重要でない。制御機器開発における種々の特徴カテゴリーに対する例は、製品特徴を有する制御機器の使用国「ヨーロッパ」、「北アメリカ」、「アジア」、または、サブ製品特徴「４個のシリンダーを有するエンジン」、「６個のシリンダーを有するエンジン」、「８個のシリンダーを有するエンジン」または「１２個のシリンダーを有するエンジン」を伴う駆動体の種類（「自己点火」、「オットー・エンジン」）、または、サブ製品特徴「リムジン」、「コンビ」、「オープンカー」を有する車両上部構造であり得る。製品特徴は、製品の種々のバリエーションが区別される考えられる特徴であり、従って製品バリエーションは、特別な製品バリエーションを特徴づける製品特徴の選択によって生じる。上述の例を取り上げるために、１つの製品バリエーションは例えば、４個のシリンダーを有する自己点火式エンジンのための、欧州市場向けの制御機器であり得る。別の製品バリエーションは、米国市場向けの自己点火式エンジンの制御機器であり、ここで、これらの異なる製品バリエーションを区別する必要性が、例えば種々の市場における種々の生産者要求から、または、例えば上述した地域における種々の法的な規準から生じる。

上述した背景から、専門領域における種々の構成要素が、特定の製品バリエーションに対してのみ有効であることが、理解できる。４個のシリンダーを有する自己点火式エンジン用の制御機器の製品バリエーションがヨーロッパとアメリカにおいて区別されるべき場合には、要求仕様の専門領域における少なくとも部分的に異なった要求、テストケースの専門領域における部分的に異なったテストケース、制御アルゴリズムの専門領域における部分的に異なった制御、または、パラメーターないしはパラメーターセットの専門領域における異なったパラメーターおよび／またはパラメーターセットが生じている可能性がある。

総体的に、特徴カテゴリーがバリエーションモデル内で変化する場合に、開発プロセス中に、製品バリエーションと構成要素の依存性を確実に追跡するという大きな問題が生じる。さらなる問題は、殊に種々の専門領域の構成要素に関する情報が散乱して格納されている場合に、特定の製品バリエーションに対して確実に、相応する有効な構成要素を特定の専門領域から求める、というものである。示された多数の開発プロジェクトを成就させ、付随する情報を一貫して保持することも問題である。バリエーションモデルにおける変更は、例えば、どの程度まで、構成要素に対する変更された製品バリエーションの関係が変化するかという問いを投げかける。

本発明の課題は、御機器開発における製品バリエーションのデータ管理と関連した上述の問題を解決することができる、コンピュータに実装される技術的なソリューションを提供することである。

上述の課題は、制御機器開発において製品バリエーションを管理するコンピュータ実装される方法であって、
まずは、
・バリエーションモデルにおいて製品特徴（１）を設定し、
・少なくとも１つの専門領域（５）において構成要素（４）を設定し、
・構成要素（４）を少なくとも１つの製品特徴（１）に割り当てることによって、特徴と構成要素の依存性（６）を規定し、
次に、
・製品特徴（１）を選択することによって、興味を抱いている、少なくとも１つの製品バリエーション（Ｖ）を設定し、
・興味を抱いている、少なくとも１つの専門領域（ＰＤ）を設定し、
・興味を抱いている、前記製品バリエーション（Ｖ）に属している前記構成要素（４）を、前記特徴と構成要素の依存性（６）を自動的に評価することによって自動的に求め、
・求められた構成要素（４）を自動的に出力する、
ことを特徴とする、コンピュータ実装される方法によって解決される。

特徴カテゴリーにおける製品特徴を有する、階層的に分かれているバリエーションモデル 製品特徴に構成要素を割り当てることによる、特徴と構成要素の依存性の規定 図１に示されている製品特徴を選択することによる、興味を抱いている製品バリエーションの規定 興味を抱いている製品バリエーションに応じた、特徴と構成要素の依存性の自動的な評価と、求められた構成要素の出力 専門領域内の構成要素の格納 第１の例に即した値依存における、興味を抱いている製品バリエーションに応じた、特徴と構成要素の依存性の自動的な評価 第２の例に即した値依存における、興味を抱いている製品バリエーションに応じた、特徴と構成要素の依存性の自動的な評価 より低い階層レベルにある製品特徴を有する製品バリエーションへの、特徴と構成要素の依存性の伝達 所定の製品特徴の消去時の衝突ケースにおける、データファイルのバージョン管理 不完全な特徴と構成要素の依存性のバージョン管理と消去による、データファイル内の矛盾の自動的な消去 バリエーションモデルおよび／または専門領域モデルの新たなバージョンの別個の作成

上述の課題は、殊に制御機器開発における製品バリエーションの、コンピュータ実装されるデータ管理方法において次のことによって解決される。すなわちはじめに、バリエーションモデルにおける製品特徴を設定し、少なくとも１つの専門領域における構成要素を設定し、特徴と構成要素の依存性を、構成要素を製品特徴に割り当てることによって定めることによって解決される。はじめに製品特徴を設定するのか構成要素を設定するのは重要ではなく、重要なのは、この方法の使用者がシステム的に製品特徴を設定すること、および、システマチックに、専門領域における構成要素を設定することが可能であるということだけである。ここでこれらの製品特徴は、複数の特徴カテゴリーに分けられる。製品特徴と構成要素の設定は、例えば、データバンクないで行われる。特徴と構成要素の依存性とは、どの構成要素がどの、１つないしは複数の製品特徴と結び付いているのか、すなわちどの製品特徴に特定の構成要素が関連しているのかを示す情報である。当然ながら１つの構成要素が、種々の製品特徴に関連していることもある。

定められた特徴と構成要素の依存性を格納することによって、本発明の方法を用いて以降で、少なくとも１つの、興味を抱いている製品バリエーションを製品特徴の選択によって設定すること、および、少なくとも１つの、興味を抱いている専門領域を設定することが可能になる。これに続いて次に自動的に、興味を抱いている製品バリエーションに属している構成要素を、興味を抱いている専門領域から、事前に設定された特徴と構成要素の依存性を自動的に評価することによって求めることができる。次に、求められた構成要素の自動的な出力が行われる。従って製品特徴を選択することによって特徴付けされた製品バリエーションはいわばフィルターとして作用する。これは、専門領域データ全体に使用され、これによって、ここから、製品バリエーションに対する、興味を抱いている構成要素を得ることができる。

特徴と構成要素の依存性の自動的な評価では例えば、全ての特徴と構成要素の依存性がくまなく調べられ、所定の、興味を抱いている製品バリエーションの少なくとも１つの製品特徴に対して関連しており、これと同時に、所定の、興味を抱いている専門領域にある構成要素と関連している依存性が抽出される。求められた構成要素の自動的な出力は、情報を提供する特徴を有している。これは例えば、事前に自動的に求められた構成要素の表示によるが、求められた構成要素がデータユニットとして出力され、さらなる処理に供されてもよい。例えば、記載されたコンピュータ実装方法を介して、いずれにせよ、所定の、興味を抱いている製品バリエーションの少なくとも１つの製品特徴と関連しており、同時に、相応するテストが行われるテストシステムに供給される全てのテストケースを求めることができる。

本発明の特に有利な構成では、バリエーションモデル、専門領域および特徴と構成要素の依存性が共通のデータベース内で検出される。この実施例では、全体的な開発プロセスは統一された共通のデータベースにおいてコピーされる。従って、このコンピュータ実装された方法はいつでも、全ての依存性の完全な情報を有することができる。共通のデータベースはここで、殊に、専門領域の構成要素に関する組織的な情報だけでなく、種々の専門領域において処理される情報自体を含んでいる。従って共通のデータベースは、特定のテストケースおよびテストシーケンスがこの制御機器に対して存在しているという情報、特定の数学的モデルが制御機器環境をシミュレーションするために存在しているという情報、および、特定のパラメーターが存在しているという情報を有しているだけでなく、むしろ、テストケース記述、テストシーケンスのコード、数学的モデルの内容的かつデータ的な記述および自身に割り当てられている値を有するパラメーターを元来有している。

例えば、数学的なモデルを作成するソフトウェアツールによって、数学的なモデルの１つが処理される場合、このようなソフトウェアツールは理想的には、共通のデータベースにアクセスする。全体的に、この方法による手法によって、クライアントサーバーシステム様式の動作環境が実装される。ここでは、全ての種々の、異なる専門領域データによって動作するクライアントは、統一されたデータベースの矛盾のない状態によって動作する。有利には、コンピュータ実装された方法は、このような場合には、完全なデータベースを有する唯一の組み込まれたアプリケーションによって実装される。このように実装された方法およびこのように設計されたデータベースではもはや、これらの専門領域に種々の開発ツールと別個のデータ管理が設けられている場合には、種々の専門領域から相応する情報を得る必要はない。製品バリエーションをデータ管理する組み込まれたソリューションの場合も依然としてそうであり得るが、いずれにせよ、バリエーションモデルに関する情報の他に種々の専門領域からの興味を抱いているデータが、統一された共通のデータベースにおいても保持される。

この方法の発展形態では、定められた、特徴と構成要素の依存性は、存在の依存性および／または値依存性である。存在の依存性の場合には、関心の情報は、少なくとも１つの製品特徴と専門領域の構成要素との間に依存性が存在するということのみである。値依存性の場合には、さらに、専門領域の関連する構成要素の後ろに隠れているデータ自体も意味を有する。すなわちこの場合には、少なくとも１つのデータが、関与している構成要素に対して予め設定されている。このようなデータは、例えば、パラメーターに付けられている値であり得る。例えば、アンチロック・ブレーキ・システムの規則におけるパラメーターＰ１は異なる値を、欧州市場向けの制御機器と、米国市場向けの制御機器に対して有することができる。このような値依存性の場合には殊に、１つまたは複数の製品特徴に対する専門領域の構成要素の間の複数の依存性の設定の場合には、各特徴の組み合わせに対して少なくとも１つのデータが格納されるように設定される。

コンピュータ実装される方法の１つの構成では、専門領域内の構成要素が別個のデータユニット内に格納され、例えば別個のファイル内に格納される。要求仕様の専門領域の場合には、これは次のことを意味する。すなわち、仕様が別個に格納され、別個のデータユニットとして使用可能であり、別の特定化と混合されて共通のデータユニット内に存在するのではない、ということを意味する。これは殊に、次の場合に有利である。すなわち、特徴と構成要素の依存性の自動的な評価が依存の存在検査において生じる、すなわち、所定の、興味を抱いている製品バリエーションと少なくとも１つの、興味を抱いている、設定された専門領域における構成要素との間に依存が存在するか否かのみが検査される場合である。この場合には、求められた構成要素と関連しているデータユニットを、特別な抽出の中間ステップなく、出力することができる。このデータユニットは、殊に、変化なく出力される。

この方法の択一的な構成では、専門領域内の構成要素は、共通のデータユニット内に格納される。従って、これらの構成要素は別個に存在しない。これは例えば、パラメーターおよびパラメーターセットの格納時には有意義である。例えば、数学的なモデルまたは調整アルゴリズムのパラメーター化のための、特定のパラメーターとパラメーターセットは、特定のパラメーターに対する異なる値のみによって区別される。しかしここでこれらのパラメーター自体は同じである、または、複数のパラメーターセットにおいて少なくとも部分的に現れる。共通のデータユニット内の、複数のパラメーターセットの送られたリストによって、極めて容易に、種々のパラメーターセットの類似性および相違に関する良好な概観を得て、伝えることができる。専門領域内の構成要素が共通のデータユニット内に格納されている場合には、特徴と構成要素の依存性の自動的な評価はまず、依存性の存在検査において生じる。ここで求められた構成要素と関連しているエントリーがこの共通のデータユニットから抽出され、出力される。この出力は同様に、情報を与える特性のみを有しているが、これは、別の自動化されたプロセスに対する抽出されたデータの提供においても用いられ、ここでこの求められたエントリーは、共通のデータユニットから、殊に別個のファイル内に出力される。

この方法の有利な構成では、製品特徴は階層的に分けて規定される。階層的に分けてとはここで次のことを意味する。すなわち製品特徴がサブ製品特徴に分けられる、ということを意味している。ここで、この階層的な構造は、より低い階層レベルのサブ製品特徴にも伝わる。このような、製品特徴の階層的な区分の例は、領域的な属性であり得る。特徴カテゴリー「国」は、例えば、製品特徴「ヨーロッパ」、「アジア」および「北アメリカ」を有することができる。製品特徴「ヨーロッパ」は、例えば、階層的に、サブ製品特徴「ドイツ」、「フランス」、「イギリス」および「その他」に分けられるだろう。特徴カテゴリーの階層的に分けた規定は、本願発明の方法の発展形態において次のことを可能にする。すなわち、より高い階層レベルの製品特徴に対して定められた、特徴と構成要素の依存性が、より低い階層レベルにある製品特徴を有するバリエーションにも伝達されることを可能にする。上述した例で説明されたことは次のことを意味する。すなわち、例えば、欧州の自己点火式エンジンのバリエーションに対して定められた構成要素の依存性が、階層的により低いランクのサブバリエーションにも拡張されることを意味する。従って、定められた構成要素の依存性は、「ドイツ」、「フランス」、「イギリス」または「その他」用に規定された自己点火式エンジンバリエーションにも有効である。このような階層的な特性は殊に、データ管理の場合に有利である。ここでは、専用領域内の構成要素が共通のデータユニット内に格納されている。従って、例えば、関連しているバリエーションに対する全パラメーターセットのテーブル形式のリストアップにおいて、特定のパラメーターが階層的に下位のバリエーションに対しても有効であるか否かが極めて容易に示され、識別される。この場合には、容易に、パラメーターが特定のバリエーションに対して存在するのか否か、すなわち存在の依存性が生じているのか否かが識別可能である。特定のバリエーションに対して、パラメーターが存在する場合には、この値も、容易に、階層的に下位のランクのバリエーションに伝達される。この下位のバリエーションはこの場合には値的に高位のランクのバリエーションに依存する。すなわち、値依存性が存在する。付加的に、階層的に下位のランクの製品バリエーションにおける値の伝達が、ここに、専用の値設定が存在しない場合のみ行われるようにすることができる。

本発明の特に有利な構成では、構成要素と複数の製品特徴との間で、複数の特徴カテゴリーにおいて、それぞれ１つの値依存性が定められる。ＶＫ１、ＶＫ２、．．．、ＶＫｎが該当する特徴カテゴリーであり、ｖｋ１、ｖｋ２、．．．、ｖｋｎが、値依存性の形態の、特徴と構成要素の依存性の各数である場合には、本発明では、構成要素に対するｖｋ１×ｖｋ２×．．．×ｖｋｎの値設定が、製品特徴の種々の組み合わせに対して行われる。

定められた特徴と構成要素の依存性は、論じられているコンピュータ実装された方法の範囲内で、依然として、一貫したデータ管理を保証するために利用される。従って、本発明による方法の１つの形態では、事前に定められた製品特徴の消去の設定時に、消去されるべき製品特徴が構成要素と関連付しているか否かが求められる。これは、現存する（vorhandenen）特徴と構成要素の依存性を評価することによって常に可能である。消去されるべき製品特徴が構成要素に関連付けされている場合には、衝突ケースが生じる。

まずは衝突ケースに気づかせる。これは、存在する特徴と構成要素の依存性が示され、消去されるべき製品特徴の消去が中止されることによって行われる。

しかしこの方法の有利な構成では、部分的なデータ損失につながり得る衝突ケースが示唆されるだけでなく、むしろ、能動的かつ自動的に、衝突の解消が提示される。これは、特徴と構成要素の依存性が存在する場合には自動的に、場合によってはユーザーによるイネーブル化の後に、管理されるデータファイル（Datenbestandes）の新しいバージョンが、管理されるデータファイルのコピーの形で作成されることによって行われる。ここで、管理されるデータファイルの新たに作成されたバージョンでは、消去されるべき製品特徴が除去される、または衝突が別の方法で解消される。例えば、より低いランクの製品特徴が消去された場合、特徴と構成要素の依存性はより高いランクの製品特徴を示すことができる。このような措置によって、消去されるべき製品特徴が、全体的に、製品特徴のデータ管理から落ちないことが保証される。このようなバージョン管理（Versionierung）によって、消去されるべき製品バリエーションが、古いバージョンで得られ続け、ここで変わらずにアクセスされる。バリエーションモデルのさらなる開発も、バリエーションモデル全体、専用領域および特徴と構成要素の依存性の開発も、このようにして、データファイルの新たなバージョンにおいて進むことができる。この方法の有利な発展形態では、消去された製品特徴と関連する、特徴と構成要素の依存性も消去される。なぜなら、２つの接続パートナーのうちの一方がもはや存在しないからである。管理されるデータファイルのコピーの作成は、殊にバリエーションモデル、専用領域、製品特徴の定義、および特徴と構成要素の依存性の定義のコピーを含む。

一貫したデータ管理を促進するためのさらなる措置では、特徴と構成要素の依存性を、消去された製品特徴に対してのみ有している構成要素が自動的に、管理されるデータファイルから消去される。このような措置を、この方法の使用者の了承を前提にして行うこともできる。従って、データファイル内での、意図しないまたは熟慮されていない消去は行われない。

新たなバーションの作成が、製品特徴の消去を前提として、有意義または必要にのみ行われるのではなく、むしろデータファイルの新たなバージョンの作成への要望が他の方法で引き起こされてもよい。これは例えば、開発状態を文書化するためである。驚くべきことに、製品バリエーションをデータ管理するための提案されたこの方法による種々のバージョンとのコンタクトが容易にサポート可能であることが明らかになった。この方法のさらなる発展形態では、次のことが実現される。すなわちバリエーションモデルの新たなバージョンが、バリエーションモデルの古いバージョンの変更可能なコピーによって作成される、および／または、全ての専用領域と全ての特徴と構成要素の依存性とから成る専用領域モデルの新たなバージョンが、専用領域モデルの古いバージョンの変更可能なコピーによって作成されることが実現される。すなわち、さらに発展した方法を用いて、バリエーションモデルおよび／または専用領域モデルの新たなバージョンを形成することが可能である。従って例えば、バリエーションモデルを新たなバージョンにおいて継続して開発することが可能であり、他方では、古いバリエーションモデルは古い専用領域モデルおよび特徴と構成要素の依存性とともに、これらの２つのモデルの間でさらに処理される。

バリエーションモデルの新たなバージョンが作成されると、新たなバージョンにおけるバリエーションモデルと、各専用領域における構成要素との間の割り当てを、再度行う要望が生じる。ここで、専用領域の新たなバージョンはまだ存在していない。従って本発明では、専用領域モデルの古いバージョンをバリエーションモデルの新たなバージョンに交換する際に、まずは、専用領域モデルの新たなバージョンが、専用領域モデルの古いバージョンをコピーすることによって作成され、バリエーションモデルの古いバージョンに関連する特徴と構成要素の依存性が自動的に、バリエーションモデルの新たなバージョンに伝達される。ここでこの自動的な伝達は、一致を見出すことによって行われる。殊に、一致の自動的な発見は、直接的に、明示的に格納されている参照を評価すること（ひいては名称に依存せずに）、バリエーションモデルの古いバージョンにおける名称および／または特徴カテゴリーの特徴の組み合わせを、バリエーションモデルの新たなバージョンにおける名称および／または特徴カテゴリーの特徴組み合わせと比較することによって、行われる。

詳細には、上述した方法を展開し、発展させる多数の方法がある。以降では、製品バリエーションをデータ管理するための本発明の方法を、実施例の後続の説明に基づいて、図面と関連して説明する。

図１には、まずは、制御機器開発における製品バリエーションのデータ管理のための、コンピュータ実装された方法の一部が示されている。これは製品特徴１の設定に関する。これらの製品特徴はさらに、複数の特徴カテゴリー２に分けられている。特徴カテゴリー２としてはここで使用場所（国）とエンジンの様式（エンジン）が示されている。製品特徴１は、製品開発時に、種々の製品バリエーション間の適切または必要な区分基準として明らかになる特徴である。

従って、特徴カテゴリー２「国」は、製品特徴「ヨーロッパ」、「アジア」および「北アメリカ」に分かれている。ここで製品特徴「ヨーロッパ」はさらなる製品特徴「ドイツ」、「イギリス」、「フランス」および「その他」に分かれている。従って製品特徴は、階層的に分けられている。同様のことが、特徴カテゴリー２「エンジン」に対して当てはまる。これは車両のエンジンに関しており、この例では、特定の制御機器がこの車両のために開発されるべきである。特徴カテゴリー２「エンジン」は従って、製品特徴１「自己点火」と「スパーク点火（オットー・エンジン）」に分かれる。この製品特徴１はその後、再び、エンジンの異なるサイズ（ここでは、シリンダーの数に依存して示されている）に分かれる。

図２は、構成要素４を製品特徴１に割り当てることによる、特徴と構成要素の依存性６の規定（Definition）を示している。図１に示されたバリエーションモデルの全ての製品特徴１はもはや詳細には示されておらず、特徴と構成要素の依存性６に関与している特徴Ｍ１、Ｍ２、・・・Ｍ６のみが示されている。特徴Ｍ１は例えば特徴カテゴリー「国」における特徴「イギリス」である。種々の専門領域５「ＰＤ−ＲＳ」、「ＰＤ−ＴＣ」および「ＰＤ−ＰＳ」内の所定の構成要素４「ＲＳ１」、．．．、「ＴＣ１」、．．．、「ＰＳ１」が見てとれる。「ＰＤ−ＲＳ」はここで、要求仕様（Requirement Specification）の専門領域を表し、「ＰＤ−ＴＣ」はテストケース（Testcases）の専門領域を表し、「ＰＤ−ＰＳ」はここでは例えば、パラメーターおよびパラメーターセット（Parametersets）の専門領域を表している。特徴と構成要素の依存性６は、構成要素４が製品特徴１に割り当てられることによって規定される。相応する割り当ては図２において接続線によって示されている。ここでは例えば構成要素４「ＲＳ１」、「ＲＳ２」が製品特徴１「Ｍ１」、「Ｍ２」、「Ｍ３」と接続されている。構成要素４「ＰＳ１」、「ＰＳ２」、「ＰＳ３」と製品特徴３「Ｍ１」−「Ｍ６」との間の、特徴と構成要素の依存性６は、図２において、見やすくするために、暗示されているだけである。製品特徴１と構成要素４に関する、完全なプロジェクション情報の図示された格納によって、データを容易に見つけることが可能になり、プロジェクトデータの変更時の不整合を比較的容易に検出することができる。

図３には、製品バリエーション３が、製品特徴１の選択によってどのように規定されるのかが示されている。製品バリエーション「Ｖ２」は例えば、特徴カテゴリー２「国」における製品特徴１「ヨーロッパ」と、特徴カテゴリー２「エンジン」における製品特徴１「自己点火」／「中型サイズ」を特徴とする。製品バリエーション３「Ｖ１」は、国特徴「イギリス」と特徴カテゴリー２「エンジン」におけるエンジン特徴１、すなわち「自己点火」／「中型サイズ」の総計に関する。いずれにせよ図３から、製品バリエーション３「Ｖ１」、「Ｖ２」がそれぞれ、製品特徴１を選択することによって規定されることが見て取れる。

図４には、興味を抱いている製品バリエーションＶとして、製品バリエーションＶ１が設定されており、興味を抱いている専門領域ＰＤとして、要求仕様の専門領域ＰＤ−ＲＳが設定されていることが示されている。事前に定められた特徴と構成要素の依存性６を自動的に評価することによって、ここで、容易に、次のような構成要素４を見つけ出すことができる。すなわち、興味を抱いている専門領域ＰＤ内にあり、これと同時に、興味を抱いている製品バリエーションＶの構成部分でもある製品特徴と関連している構成要素である。最終的に、求められた構成要素４、ここでは構成要素ＲＳ１およびＲＳ２の自動的な出力が行われる。なぜなら、上述した想定では、製品特徴Ｍ１は製品特徴「イギリス」を表しており、ここで専門領域５「ＰＤ−ＲＳ」内では、構成要素４「ＲＳ１」および「ＲＳ２」のみが、特徴Ｍ１と、特徴と構成要素の依存性６を介して、関係しているからである。

図示の実施例では、バリエーションモデル１、専門領域５および特徴と構成要素の依存性６が共通のデータベース内に含まれている。すなわち、データは組み込みソフトウェアソリューションにおいて管理され、データを種々のソフトウェアインタフェースを介して別のアプリケーションから探し集める必要はない。当然ながら、共通のデータベース内に含まれている情報は、組み込みソフトウェアソリューションの構成部分ではない種々のアプリケーションによって利用および処理可能であろう；処理されるべきデータと種々のプロジェクトグループによっても処理されたデータは、ここで中央で組織化され、従って全体としてクライアント・サーバー構造になる。

図５は、テストケースの専門領域５「ＰＤ−ＴＣ」内の構成要素４「ＴＣ１」、・・・「ＴＣＮ」が別個のデータユニット内に格納されていることを示している。これは、各テストケースの枠によって示されている。ここで、製品特徴「Ｍ２」が、特徴カテゴリー２「国」における製品特徴「ヨーロッパ」の省略形であると仮定される。図２に示されている特徴と構成要素の依存性６を考慮して、興味を抱いている製品バリエーションＶ＝Ｖ２の設定と、興味を抱いている専門領域ＰＤ＝ＰＤ−ＴＣを設定することによって、関連する構成要素４、すなわち「ＴＣ１」、「ＴＣ２」および「ＴＣ３」の抽出が行われる。抽出された構成要素４は単に、特徴と構成要素の依存性６を自動的に評価することによって見出された。ここでこの自動的な評価は、依存性の純粋な存在検査にある。専門領域５「ＰＤ−ＴＣ」内の構成要素４が別個のデータユニット内に格納されていることによって、求められた構成要素４「ＴＣ１」、「ＴＣ２」、「ＴＣ３」を変えられていないデータユニットの形で出力することが容易になる。

図６と図７は、方法の特別ケースを示している。これらは、値依存性として分類された特徴と構成要素の依存性６の取り扱いに関する。図６においてまずは、パラメーターの専門領域５「ＰＤ−ＰＡＲ」が構成要素４「ＰＳ１」、「ＰＳ２」および「ＰＳ３」を有していることが見て取れる。パラメーターＰ１と関連している２つの特徴と構成要素の依存性６が定義されている。すなわち一方は製品特徴１「ヨーロッパ」であり、他方は、製品特徴１「アメリカ」である。２つの特徴と構成要素の依存性６は値依存性として分類されているので、まずは、構成要素Ｐ１に対する値の設定が必要であり、詳細には、特徴と構成要素の依存性６の数によって１つの特徴カテゴリー２「国」内で設定される数において必要である。この方法において必要な値の設定は、図６の中央に示されている。パラメーターＰ１は、特徴１「ヨーロッパ」に対する依存性に対して値３．１を得ており、製品特徴１「アメリカ」に対する依存性に対しては値３．７を得る。興味を抱いている製品バリエーションＶとして、製品バリエーションＶ１、Ｖ２、Ｖ３が規定されている。興味を抱いている製品バリエーションＶ１は、製品特徴組み合わせドイツ／Ｖ６（スパーク）にあり、興味を抱いている製品バリエーションＶ２は、特徴組み合わせフランス／Ｖ８（自己）に相当し、製品バリエーションＶ３は特徴組み合わせアメリカ／Ｖ８（スパーク）／オープンカーに相当する。

図６の一番下には、興味を抱いている、種々の製品バリエーションＶ１、Ｖ２、Ｖ３の使用によって、どの結果がもたらされるのかが示されている。興味を抱いている製品バリエーションＶとして選択的にＶ１、Ｖ２またはＶ３が使用され、興味を抱いている専門領域ＰＤとして、パラメーターの専門領域５「ＰＤ−ＰＡＲ」が選択されたと仮定すると、パラメーターＰ１に対して、興味を抱いている製品バリエーションＶ１、Ｖ２の場合にはそれぞれ値３．１が得られ、パラメーターＰ１に対して、興味を抱いている製品バリエーションＶ３の場合には値３．７が得られる。特徴と構成要素の依存性６の検査時にはここで、別の実施例に基づいて既に説明されたように設定がされる。付加的にここで、１つの手法が使用され、これに従って、より高い階層レベルにある製品特徴１に対して定められた特徴と構成要素の依存性６（ここでは製品特徴１「ヨーロッパ」に対するパラメーターＰ１の依存性）が、より低い階層レベルにある製品特徴を有している製品バリエーションにも伝達される。この例では、これは次のことを意味する。すなわち、製品特徴「ヨーロッパ」に対するパラメーターＰ１「Ｐ１＿ヨーロッパ」に対する設定が、国の製品特徴「ドイツ」および「フランス」に対しても使用される、ということを意味する。なぜなら、これは、製品特徴１「ヨーロッパ」の下方の、より低い階層レベルにあるからである。興味を抱いている製品バリエーションＶ１、Ｖ２に対するパラメーターＰ１に対する値は、枠で示されており、これによって、１つのデータ保存記録にこの値が基づいていること、すなわち、この場合には、パラメーターＰ１（値設定７）に対する、製品特徴１「ヨーロッパ」に対するデータ保存記録に基づいていることが示される。

図７には、より複雑な例が示されている。この例は、特徴と構成要素の依存性６に基づいている。これは同様に、値依存性として分類されている。図６における例とは異なり、ここで特徴１は、２つの特徴カテゴリー２、すなわち国とエンジンにおいて設定されている。パラメーター「ＰＤ−ＰＡＲ」の専門領域５における構成要素４「ＰＳ１」は、ここで、４つの特徴と構成要素の依存性６を有している。これらは、特徴１を２つの異なる特徴カテゴリー２において示している。特徴と構成要素の依存性６の、種々の特徴カテゴリー２に対する属性によって、パラメーターＰＳ１には、全ての可能な特徴組み合わせに対してデータが付される。これは値設定７において行われる。値設定７は次のように展開される。すなわち、これが、製品特徴１の組み合わせ可能なまとめを可能にするように行われる。各２つの製品特徴１に対する特徴と構成要素の依存性６が、２つの異なる特徴カテゴリー２において生じているので、２×２＝４の値設定を行えることが必要である。興味を抱いている製品バリエーションＶは、図６でのものと同一であり、種々の、興味を抱いている製品バリエーションＶ１、Ｖ２、Ｖ３でのフィルタリングプロセスとまさに同じである。これは、相応するフィルタリングにおいて、図７の下に示されている結果をもたらす。構成要素４「ＰＳ１」が１つの特徴カテゴリーに対して２つの依存性を有し、第２の特徴カテゴリーに対して２０の依存性を有している場合には、このパラメーターに対して２×２０＝４０の値に対する値設定が行われなければならない。

図８には、製品バリエーションのデータ管理のための方法の別の形態が示されている。ここでは階層的に分けられた特徴カテゴリーにおける値依存性の存在が使用される。ここでは、図１に示されたバリエーションモデルから出発する。ここでは、上述したように、国の識別「国」もエンジンの識別「エンジン」も階層的に分けられている。この実施例では、構成要素４、ここではパラメーターＰ１、・・・、Ｐ４に対して具体的な値が、製品バリエーションＶ１に関して、すなわち値ａ、ｂ、ｃおよびｄの形で設定されている。ここでデータベースから、バリエーションＶ２およびＶ３に対して有効なパラメーターが抽出されるべき場合、これらのパラメーターを国およびエンジンの特徴カテゴリー内の階層的な依存性に基づいて、自動的に求めることができる。

中型サイズのオットーエンジンに対する、イギリスに用いられるべき制御機器の製品バリエーションＶ２に対しては、パラメーター値は設定されていない。この場合には、高い階層レベルにある製品特徴に対して定められた特徴と構成要素との依存性が、より低い階層レベルにある製品特徴が有しているバリエーションにも伝達される。すなわちこの場合には、より高い階層レベルにある、ヨーロッパに対する製品バリエーションＶ１の設定が、エンジンのタイプが同じ場合には、イギリス、すなわち製品バリエーションＶ２にも伝達される。しかし、少なくとも部分的に、製品バリエーションＶ２に対して、幾つかのパラメーターに値が付けられているべき場合には、局部的に設定されたこの値は、階層的な値依存性によって伝達され得る値よりも優位にある。８つのシリンダーを有するオットーエンジンに関する限りは、全ての他のヨーロッパの国の制御機器に対して有効である同じ原理が製品バリエーションＶ３に対しても使用される。ここでも、階層特性に基づいて、製品バリエーションＶ１に対して設定されたパラメーターａ、ｂ、ｃ、ｄが製品バリエーションＶ３に伝達可能である。パラメーターの依存性が特徴カテゴリー「国」にのみ関する限り、製品バリエーションＶ１およびＶ２におけるエンジンタイプの選択は重要でない、ということが大事である。

図９ａ、９ｂには、バリエーションモデルおよび／または専用領域モデルの変化時に、どのように、生じそうな特定の不整合が識別され、回避されるのかが示されている。図９ａでは、前に定められた製品特徴３「Ｍ４」の消去が設定されており、これは線で消された製品特徴Ｍ４によって表されている。ここで、現存している特徴と構成要素の依存性６を評価することによって、消去されるべき製品特徴１「Ｍ４」が構成要素４と関連を有しているか否かが求められる。存在する結合が見つけられると、現存している特徴と構成要素の依存性６が示される。これは図９ａに、鎖線で示されている。消去されるべき製品特徴Ｍ４の消去が中断される。図９ｂには、図９ａに示された方法の拡張が示されている。これによって、生じ得る衝突が示されているだけでなく、むしろ、これが取り除かれ、データ管理における不整合が回避される。図９ａに示されているような現存している特徴と構成要素の依存性６の存在の識別後、管理されるデータファイルの新たなバージョンＶｅｒ．２が、管理されるデータファイルのコピーの形で作成される。前に有効であったデータファイルは同様にバージョン管理される。これは図９ａにおいて、Ｖｅｒ．１によって示されている。管理されるデータファイルの新たに作成されたバージョンＶｅｒ．２において、消去されるべき製品特徴Ｍ４は除去される。従って、空をつかむ特徴と構成要素の依存性は生じない、ないしは残らない。

図１０ａ、１０ｂでは、この方法のさらに発展したバリエーションが示されている。図９ａ、９ｂにおける例とは異なり、図１０ａ、１０ｂでは、製品特徴Ｍ４およびＭ５の形の製品特徴１が消去されるべきであることが設定されている。図９におけるのと同じように、まずは、消去されるべき製品特徴Ｍ４およびＭ５が構成要素４と関連しており、衝突が生じ得るか否かが検査される。図９にも示されているように、このような依存性が識別されると、管理されているデータファイルのコピーが作成される（Ｖｅｒ．２）。ここでは、消去されるべき製品特徴Ｖ４およびＶ５のみが、管理されるデータファイルの新たに作成されたバージョンＶｅｒ．２において除去されるのではなく、消去された製品特徴Ｍ４、Ｍ５と関連している特徴と構成要素の依存性６も除去される。これは、図９に示された実施例の場合には、容易に可能ではなかった。なぜなら、構成要素ＲＳ３はここでは、依然として別の製品特徴１、すなわち製品特徴Ｍ５と関連しているからである。

図１１には、本発明の方法の発展形態が示されている。ここでは、バリエーションモデルの新たなバージョンＶｅｒ．２が、バリエーションモデルの古いバージョンＶｅｒ．１の変更可能なコピーによって作成される。択一的に、全ての専用領域５と全ての特徴と構成要素の依存性６とから成る専用領域モデルの新たなバージョンＶｅｒ．２も、専用領域モデルの古いバージョンＶｅｒ．１の変更可能なコピーによって作成される。いずれにせよ重要なのは、このようなコピーがバリエーションモデルおよび専用領域モデルの次のバージョン番号の設定のもとで、相互に依存しないで作成可能である、ということである。図１１に示された例ではいずれにせよ、まずは、バリエーションモデルの新たなバージョンＶｅｒ．２が作成される。これは、丸１によって示されている。

次に、バリエーションモデルのバージョンＶｅｒ．２が変えられ、例えば、製品特徴Ｍ４が消去され、付加的に製品特徴Ｍ２’およびＭ６が生じる。バリエーションモデルがバージョンＶｅｒ．２においてバージョンＶｅｒ．１に対して変更された後、専用領域モデルを同様に、バリエーションモデルのバージョンＶｅｒ．２に伝達する要望が生じる。このため、バリエーションモデルの古いバージョンＶｅｒ．１から、バリエーションモデルの新たなバージョンＶｅｒ．２への変更時に、まずは、専用領域モデルの新たなバージョンＶｅｒ．２が、専用領域モデルの古いバージョンＶｅｒ．１をコピーすることによって作成され、バリエーションモデルの古いバージョンＶｅｒ．１と関連している特徴と構成要素の依存性６が自動的に、参照を評価することによって、または、一致を評価することによって、バリエーションモデルの新たなバージョンＶｅｒ．２に伝達される。古いバージョンＶｅｒ．１から新たなバージョンＶｅｒ．２への専用領域モデルのコピーは、図１１において、丸２が付けられたステップによって示されている。見やすくするために、次のことを言及しておく。すなわち、バージョンＶｅｒ．２への専用領域モデルのコピーの直後に、構成要素４に基づく、特徴と構成要素の依存性６が、依存として、バージョンＶｅｒ．１におけるバリエーションモデルの製品特徴と関連している、ということを言及しておく。これは図１１には詳細に示されていない。データファイルの種々のバージョン間の、これらの特徴と構成要素の依存性６は、上述のように、参照または一致の評価によって、バージョンＶｅｒ．２における製品バリエーションに自動的に「歪曲される」。これは、丸３が付けられているステップに相応する。

１ 製品特徴、 ２ 特徴カテゴリー、 ３ 製品バリエーション、 ４ 構成要素、 ５ 専門領域、 ６ 特徴と構成要素の依存性、 ７ 値設定

この方法の有利な構成では、製品特徴は階層的に分けて規定される。階層的に分けてとはここで次のことを意味する。すなわち製品特徴がサブ製品特徴に分けられる、ということを意味している。ここで、この階層的な構造は、より低い階層レベルのサブ製品特徴にも伝わる。このような、製品特徴の階層的な区分の例は、領域的な属性であり得る。特徴カテゴリー「国」は、例えば、製品特徴「ヨーロッパ」、「アジア」および「北アメリカ」を有することができる。製品特徴「ヨーロッパ」は、例えば、階層的に、サブ製品特徴「ドイツ」、「フランス」、「イギリス」および「その他」に分けられるだろう。特徴カテゴリーの階層的に分けた規定は、本願発明の方法の発展形態において次のことを可能にする。すなわち、より高い階層レベルの製品特徴に対して定められた、特徴と構成要素の依存性が、より低い階層レベルにある製品特徴を有するバリエーションにも伝達されることを可能にする。上述した例で説明されたことは次のことを意味する。すなわち、例えば、欧州の自己点火式エンジンのバリエーションに対して定められた構成要素の依存性が、階層的により低いランクのサブバリエーションにも拡張されることを意味する。従って、定められた構成要素の依存性は、「ドイツ」、「フランス」、「イギリス」または「その他」用に規定された自己点火式エンジンバリエーションにも有効である。このような階層的な特性は殊に、データ管理の場合に有利である。ここでは、専門領域内の構成要素が共通のデータユニット内に格納されている。従って、例えば、関連しているバリエーションに対する全パラメーターセットのテーブル形式のリストアップにおいて、特定のパラメーターが階層的に下位のバリエーションに対しても有効であるか否かが極めて容易に示され、識別される。この場合には、容易に、パラメーターが特定のバリエーションに対して存在するのか否か、すなわち存在の依存性が生じているのか否かが識別可能である。特定のバリエーションに対して、パラメーターが存在する場合には、この値も、容易に、階層的に下位のランクのバリエーションに伝達される。この下位のバリエーションはこの場合には値的に高位のランクのバリエーションに依存する。すなわち、値依存性が存在する。付加的に、階層的に下位のランクの製品バリエーションにおける値の伝達が、ここに、専用の値設定が存在しない場合のみ行われるようにすることができる。

しかしこの方法の有利な構成では、部分的なデータ損失につながり得る衝突ケースが示唆されるだけでなく、むしろ、能動的かつ自動的に、衝突の解消が提示される。これは、特徴と構成要素の依存性が存在する場合には自動的に、場合によってはユーザーによるイネーブル化の後に、管理されるデータファイル（Datenbestandes）の新しいバージョンが、管理されるデータファイルのコピーの形で作成されることによって行われる。ここで、管理されるデータファイルの新たに作成されたバージョンでは、消去されるべき製品特徴が除去される、または衝突が別の方法で解消される。例えば、より低いランクの製品特徴が消去された場合、特徴と構成要素の依存性はより高いランクの製品特徴を示すことができる。このような措置によって、消去されるべき製品特徴が、全体的に、製品特徴のデータ管理から落ちないことが保証される。このようなバージョン管理（Versionierung）によって、消去されるべき製品バリエーションが、古いバージョンで得られ続け、ここで変わらずにアクセスされる。バリエーションモデルのさらなる開発も、バリエーションモデル全体、専門領域および特徴と構成要素の依存性の開発も、このようにして、データファイルの新たなバージョンにおいて進むことができる。この方法の有利な発展形態では、消去された製品特徴と関連する、特徴と構成要素の依存性も消去される。なぜなら、２つの接続パートナーのうちの一方がもはや存在しないからである。管理されるデータファイルのコピーの作成は、殊にバリエーションモデル、専門領域、製品特徴の定義、および特徴と構成要素の依存性の定義のコピーを含む。

新たなバーションの作成が、製品特徴の消去を前提として、有意義または必要にのみ行われるのではなく、むしろデータファイルの新たなバージョンの作成への要望が他の方法で引き起こされてもよい。これは例えば、開発状態を文書化するためである。驚くべきことに、製品バリエーションをデータ管理するための提案されたこの方法による種々のバージョンとのコンタクトが容易にサポート可能であることが明らかになった。この方法のさらなる発展形態では、次のことが実現される。すなわちバリエーションモデルの新たなバージョンが、バリエーションモデルの古いバージョンの変更可能なコピーによって作成される、および／または、全ての専門領域と全ての特徴と構成要素の依存性とから成る専門領域モデルの新たなバージョンが、専門領域モデルの古いバージョンの変更可能なコピーによって作成されることが実現される。すなわち、さらに発展した方法を用いて、バリエーションモデルおよび／または専門領域モデルの新たなバージョンを形成することが可能である。従って例えば、バリエーションモデルを新たなバージョンにおいて継続して開発することが可能であり、他方では、古いバリエーションモデルは古い専門領域モデルおよび特徴と構成要素の依存性とともに、これらの２つのモデルの間でさらに処理される。

バリエーションモデルの新たなバージョンが作成されると、新たなバージョンにおけるバリエーションモデルと、各専門領域における構成要素との間の割り当てを、再度行う要望が生じる。ここで、専門領域の新たなバージョンはまだ存在していない。従って本発明では、専門領域モデルの古いバージョンをバリエーションモデルの新たなバージョンに交換する際に、まずは、専門領域モデルの新たなバージョンが、専門領域モデルの古いバージョンをコピーすることによって作成され、バリエーションモデルの古いバージョンに関連する特徴と構成要素の依存性が自動的に、バリエーションモデルの新たなバージョンに伝達される。ここでこの自動的な伝達は、一致を見出すことによって行われる。殊に、一致の自動的な発見は、直接的に、明示的に格納されている参照を評価すること（ひいては名称に依存せずに）、バリエーションモデルの古いバージョンにおける名称および／または特徴カテゴリーの特徴の組み合わせを、バリエーションモデルの新たなバージョンにおける名称および／または特徴カテゴリーの特徴組み合わせと比較することによって、行われる。

図９ａ、９ｂには、バリエーションモデルおよび／または専門領域モデルの変化時に、どのように、生じそうな特定の不整合が識別され、回避されるのかが示されている。図９ａでは、前に定められた製品特徴３「Ｍ４」の消去が設定されており、これは線で消された製品特徴Ｍ４によって表されている。ここで、現存している特徴と構成要素の依存性６を評価することによって、消去されるべき製品特徴１「Ｍ４」が構成要素４と関連を有しているか否かが求められる。存在する結合が見つけられると、現存している特徴と構成要素の依存性６が示される。これは図９ａに、鎖線で示されている。消去されるべき製品特徴Ｍ４の消去が中断される。図９ｂには、図９ａに示された方法の拡張が示されている。これによって、生じ得る衝突が示されているだけでなく、むしろ、これが取り除かれ、データ管理における不整合が回避される。図９ａに示されているような現存している特徴と構成要素の依存性６の存在の識別後、管理されるデータファイルの新たなバージョンＶｅｒ．２が、管理されるデータファイルのコピーの形で作成される。前に有効であったデータファイルは同様にバージョン管理される。これは図９ａにおいて、Ｖｅｒ．１によって示されている。管理されるデータファイルの新たに作成されたバージョンＶｅｒ．２において、消去されるべき製品特徴Ｍ４は除去される。従って、空をつかむ特徴と構成要素の依存性は生じない、ないしは残らない。

図１１には、本発明の方法の発展形態が示されている。ここでは、バリエーションモデルの新たなバージョンＶｅｒ．２が、バリエーションモデルの古いバージョンＶｅｒ．１の変更可能なコピーによって作成される。択一的に、全ての専門領域５と全ての特徴と構成要素の依存性６とから成る専門領域モデルの新たなバージョンＶｅｒ．２も、専門領域モデルの古いバージョンＶｅｒ．１の変更可能なコピーによって作成される。いずれにせよ重要なのは、このようなコピーがバリエーションモデルおよび専門領域モデルの次のバージョン番号の設定のもとで、相互に依存しないで作成可能である、ということである。図１１に示された例ではいずれにせよ、まずは、バリエーションモデルの新たなバージョンＶｅｒ．２が作成される。これは、丸１によって示されている。

次に、バリエーションモデルのバージョンＶｅｒ．２が変えられ、例えば、製品特徴Ｍ４が消去され、付加的に製品特徴Ｍ２’およびＭ６が生じる。バリエーションモデルがバージョンＶｅｒ．２においてバージョンＶｅｒ．１に対して変更された後、専門領域モデルを同様に、バリエーションモデルのバージョンＶｅｒ．２に伝達する要望が生じる。このため、バリエーションモデルの古いバージョンＶｅｒ．１から、バリエーションモデルの新たなバージョンＶｅｒ．２への変更時に、まずは、専門領域モデルの新たなバージョンＶｅｒ．２が、専門領域モデルの古いバージョンＶｅｒ．１をコピーすることによって作成され、バリエーションモデルの古いバージョンＶｅｒ．１と関連している特徴と構成要素の依存性６が自動的に、参照を評価することによって、または、一致を評価することによって、バリエーションモデルの新たなバージョンＶｅｒ．２に伝達される。古いバージョンＶｅｒ．１から新たなバージョンＶｅｒ．２への専門領域モデルのコピーは、図１１において、丸２が付けられたステップによって示されている。見やすくするために、次のことを言及しておく。すなわち、バージョンＶｅｒ．２への専門領域モデルのコピーの直後に、構成要素４に基づく、特徴と構成要素の依存性６が、依存として、バージョンＶｅｒ．１におけるバリエーションモデルの製品特徴と関連している、ということを言及しておく。これは図１１には詳細に示されていない。データファイルの種々のバージョン間の、これらの特徴と構成要素の依存性６は、上述のように、参照または一致の評価によって、バージョンＶｅｒ．２における製品バリエーションに自動的に「歪曲される」。これは、丸３が付けられているステップに相応する。

Claims (18)

1. 制御機器開発において製品バリエーションをデータ管理するコンピュータ実装される方法であって、
   まずは、
   ・バリエーションモデルにおいて製品特徴（１）を設定し、
   ・少なくとも１つの専門領域（５）において構成要素（４）を設定し、
   ・構成要素（４）を少なくとも１つの製品特徴（１）に割り当てることによって、特徴と構成要素の依存性（６）を規定し、
   次に、
   ・製品特徴（１）を選択することによって、興味を抱いている、少なくとも１つの製品バリエーション（Ｖ）を設定し、
   ・興味を抱いている、少なくとも１つの専門領域（ＰＤ）を設定し、
   ・興味を抱いている、前記製品バリエーション（Ｖ）に属している前記構成要素（４）を、前記特徴と構成要素の依存性（６）を自動的に評価することによって自動的に求め、
   ・求められた構成要素（４）を自動的に出力する、
   ことを特徴とする、コンピュータ実装される方法。
2. バリエーションモデルと、専門領域（５）と、特徴と構成要素の依存性（６）とを共通のデータベース内に含む、請求項１記載のコンピュータ実装される方法。
3. 前記規定された、特徴と構成要素の依存性（６）は、存在依存性および／または値依存性である、請求項１または２記載のコンピュータ実装される方法。
4. 専門領域（５）内の前記構成要素（４）を、別個のデータユニット内に格納する、請求項１から３までのいずれか１項記載のコンピュータ実装される方法。
5. 前記特徴と構成要素の依存性（６）の自動的な評価は、前記依存性の存在検査にあり、殊にここで、前記求められた構成要素（４）と関連しているデータユニットを変更せずに格納する、請求項４記載のコンピュータ実装される方法。
6. 専門領域（５）内の前記構成要素（４）を、共通のデータユニット内に格納する、請求項１から３までのいずれか１項記載のコンピュータ実装される方法。
7. 前記特徴と構成要素の依存性（６）の自動的な評価は、前記依存性の存在検査にあり、ここで、前記求められた構成要素（４）と関連しているエントリーを、前記共通のデータユニットから抽出して、出力する、請求項６記載のコンピュータ実装される方法。
8. 前記求められた構成要素（４）と関連しているエントリーを、前記共通のデータユニットから抽出し、各エントリーを別個に出力する、殊に、別個のファイルに出力する、請求項７記載のコンピュータ実装される方法。
9. 前記製品特徴（４）を少なくとも１つの特徴カテゴリー（２）において、階層的に分けて規定する、請求項１から８までのいずれか１項記載のコンピュータ実装される方法。
10. より高い階層レベルにある製品特徴（１）に対して規定された、特徴と構成要素の依存性（６）を、より低い階層レベルにある製品特徴（１）を有している製品バリエーション（Ｖ）にも伝達し、殊に、これによって伝達される構成要素（４）はパラメーターである、請求項９記載のコンピュータ実装される方法。
11. 構成要素（４）と複数の特徴カテゴリー（ＶＫ）内の複数の製品特徴（１）との間で、それぞれ値依存性を規定し、殊に、構成要素（４）に対するｖｋ１×ｖｋ２×．．．×ｖｋｎの値設定を製品特徴（１）の種々の組み合わせに対して行い、ここでｖｋ１、ｖｋ２、．．．、ｖｋｎは、種々の特徴カテゴリーＶＫ１、ＶＫ２、．．．、ＶＫｎにおける、値依存性の形態での特徴と構成要素の依存性（６）の数である、請求項９または１０記載のコンピュータ実装される方法。
12. 構成要素（４）として、前記製品テストの専門領域におけるテストケースを設定する、および／または、構成要素（４）として前記製品モデルの専門領域におけるモデルを設定する、および／または、構成要素（４）として、前記製品パラメーターの専門領域におけるパラメーターおよび／またはパラメーターセットを設定する、および／または、構成要素（４）として、前記要求仕様の専門領域における要求を設定する、および／または構成要素として、前記テストシステムの専門領域におけるテストシステム記述を設定する、請求項１から１１までのいずれか１項記載のコンピュータ実装される方法。
13. 事前に定められた製品特徴（１）の消去の設定時に、現存する前記特徴と構成要素の依存性（６）の評価によって、消去されるべき製品特徴（１）が構成要素（４）と関連しているか否かを求め、現存する特徴と構成要素の依存性（６）を示し、ここで有利には、前記消去されるべき製品特徴（１）の消去を中断する、請求項１から１２までのいずれか１項記載のコンピュータ実装される方法。
14. 現存する特徴と構成要素の依存性（６）が存在する場合には、自動的に、場合によってはユーザーによるイネーブル化の後に、管理されるデータファイルの新たなバージョン（Ｖｅｒ．２）を、前記管理されるデータファイルのコピーの形で作成し、
    ここで前記管理されるデータファイルの新たに作成されたバージョン（Ｖｅｒ．２）において、前記消去されるべき製品特徴（１）を除去し、
    ここで殊に、前記消去された製品特徴（１）と関連する特徴と構成要素の依存性（６）も消去する、請求項１３記載のコンピュータ実装される方法。
15. 前記消去された製品特徴（１）に対してのみ特徴と構成要素の依存性（６）を有している構成要素（４）を、管理されるデータファイルから自動的に消去する、請求項１４記載のコンピュータ実装される方法。
16. 前記バリエーションモデルの新たなバージョン（Ｖｅｒ．２）を、前記バリエーションモデルの古いバージョン（Ｖｅｒ．１）の変更可能なコピーによって作成する、および／または、全ての専門領域（５）と全ての特徴と構成要素の依存性（６）とから成る専用領域モデルの新たなバージョン（Ｖｅｒ．２）を、専用領域モデルの古いバージョン（Ｖｅｒ．１）の変更可能なコピーによって作成する、請求項１から１５までのいずれか１項記載のコンピュータ実装される方法。
17. 前記バリエーションモデルの新たなバージョン（Ｖｅｒ．２）への、専用領域モデルの古いバージョン（Ｖｅｒ．１）の交換時に、まずは、前記専用領域モデルの新たなバージョン（Ｖｅｒ．２）を、前記専用領域モデルの古いバージョン（Ｖｅｒ．１）のコピーによって作成し、前記バリエーションモデルの古いバージョン（Ｖｅｒ．１）と関連する特徴と構成要素の依存性（６）を自動的に、コピーされた参照、および／または、一致、および／または、前記バリエーションモデルの新たなバージョン（Ｖｅｒ．２）におけるマーカの使用によって伝達する、請求項１６記載のコンピュータ実装される方法。
18. 一致の自動的な発見を、前記バリエーションモデルの古いバージョン（Ｖｅｒ．１）における名称および／または特徴カテゴリーの特徴の組み合わせを、前記バリエーションモデルの新たなバージョン（Ｖｅｒ．２）における名称および／または特徴カテゴリー（２）の特徴組み合わせと比較することによって行う、請求項１７記載のコンピュータ実装される方法。

Images