(57)【要約】【課題】統一モデル化言語への変換として、オブジェクト・ベースの順序概念の範囲内における自動車内メカトロニク・システムのモデル化方法および装置を提供する。【解決手段】メカトロニク・システムが、構成要素間に、問い合わせ、要求および指令のような所定の通信連絡が存在する複数の前記構成要素からなる、自動車内メカトロニク・システムのモデル化方法において、変換規定が設けられており、それにより、システムの構成要素および連絡が、オブジェクト指向のモデル化言語、好ましくはＵＭＬ言語の構成に変換される、。【選択図】図３
2004504972.tif 000002
【特許請求の範囲】
【請求項１】
メカトロニク・システムが、構成要素間に所定の通信連絡が存在する複数の前記構成要素からなる、自動車内メカトロニク・システムのモデル化方法において、
前記構成要素および前記構成要素間の通信連絡が、オブジェクト指向のモデル化言語の範囲内で表わされること、
を特徴とする自動車内メカトロニク・システムのモデル化方法。
【請求項２】
前記オブジェクト指向のモデル化言語が統一モデル化言語であることを特徴とする請求項１のモデル化方法。
【請求項３】
前記構成要素および連絡に基づいて、ソフトウェア設計を提供可能であることを特徴とする請求項１または２のモデル化方法。
【請求項４】
メカトロニク・システムが、構成要素間に、問い合わせ、要求および指令のような所定の通信連絡が存在する複数の前記構成要素からなる、自動車内メカトロニク・システムのモデル化方法において、
変換規定が設けられており、該変換規定により、前記システムの構成要素および連絡が、オブジェクト指向のモデル化言語、好ましくはＵＭＬ言語の構成に変換されること、
を特徴とする自動車内メカトロニク・システムのモデル化方法。
【請求項５】
前記変換規定は、外枠を含む構成要素が、ステレオタイプ《ｋｏｏｒｄｉｎａｔｏｒ（調整部）》、《ｏｐｅｒａｔｏｒ（オペレータ）》、《ｉｎｆｏｒｍａｔｉｏｎｓｇｅｂｅｒ（情報提供部）》および《ｈｕｅｌｌｅ（外枠）》を有するＵＭＬクラスないしオブジェクトに変換されること、通信連絡、即ち問い合わせおよび要求が、ステレオタイプ《ａｂｆｒａｇｅ（問い合わせ）》および《ａｎｆｏｒｄｅｒｕｎｇ（要求）》を有するＵＭＬオペレーションとして、ステレオタイプの《ｉｎｔｅｒｆａｃｅ（インタフェース）》を有するインタフェース内で供給されること、且つすべての指令オペレーションが、ステレオタイプ《ｉｎｔｅｒｆａｃｅＡｕｆｔｒａｇ（指令インタフェース）》を有するインタフェース内でステレオタイプ《ａｕｆｔｒａｇ（指令）》により表わされることからなることを特徴とする請求項４のモデル化方法。
【請求項６】
構成要素間に所定の通信連絡が存在する複数の前記構成要素からなる自動車内メカトロニク・システムのモデル化装置において、
前記構成要素および前記構成要素間の通信連絡が、オブジェクト指向のソフトウェア言語の範囲内で表わされること、
を特徴とする自動車内メカトロニク・システムのモデル化装置。
【請求項７】
前記構成要素間に所定の通信連絡が存在する複数の前記構成要素からなる自動車内メカトロニク・システムのモデル化装置において、
前記システムの構成要素および連絡が、変換規定によりオブジェクト指向のモデル化言語、好ましくはＵＭＬ言語の構成に変換される、前記変換規定が設けられていること、
を特徴とする自動車内メカトロニク・システムのモデル化装置。
【発明の詳細な説明】
【０００１】
発明の属する技術分野
本発明は、自動車内メカトロニク・システムのモデル化方法および装置に関するものである。
【０００２】
従来の技術
安全性、経済性、快適性並びにより良好な環境調和性に対する要求は、車両内メカトロニクスを、ますます重要で且つ競争のためにさらに不可欠な要因とさせた。生産サイクルがますます短くなっていくときに、経済的な車両開発および複雑なシステム構成の解消は、できるだけ広範囲に自動化され且つコンピュータにより支援された、一貫性のある開発過程を特に要求する。分析過程において、自動車メーカーおよび下請業者に中立な順序概念である「カートロニク」（Ｃａｒｔｒｏｎｉｃ）の、取り決められ且つ形式化された構造化規則およびモデル化規則に基づいて、「機能」、「安全性」および「エレクトロニクス」に対する、モジュール化され且つ拡張可能なアーキテクチュアを使用することができる。
【０００３】
メカニクスからエレクトロニクスを経る情報技術への技術変遷において、より高い安全性、経済性、快適性およびより良好な環境調和性に対する要求は、車両内メカトロニクスを、ますます重要で且つ競争のためにさらに不可欠な要因とさせた。システムの複雑性がますます増大し且つ同時に生産サイクルがさらに短くなっていくときに、コスト費用および開発費用は、できるだけ広範囲に自動化され且つコンピュータにより支援され、並びに十分に平行して行われる、一貫性のある作業過程および開発過程を使用したときにのみ低減可能となる。
【０００４】
部分に分散された要求を解決するためのスタートは、従来相互にほぼ独立して作動していた個別システムを、車両範囲内の結合システムにネットワーク化すること、およびシステム構成要素を、標準化インタフェースを有する機能ユニットに論理的に集約することである。システム結合は、センサ装置並びにアクチュエータ装置の協調およびそれらの複数利用の可能性、したがって非常機能を有効化する可能性を提供する。
【０００５】
さらに、ネットワーク化は、純粋に機能指向の構成から、構成において適用機能がネットワーク化制御装置に変換される前記構成への移行を可能にする。さらに、部分的なシステム故障において、機能を他のシステムに動的に移すことが支援される。
【０００６】
その標準化インタフェースを有する論理的機能ユニットから出発して、同様に、起点が異なる機能、即ち異なる自動車メーカーおよび下請業者の機能を相互にネットワーク化することが可能となる。この場合、機能提供者は、機能が複数のネットワーク化制御装置に分配されたときにおいても、要求された仕様を含むことを保証しなければならない。
【０００７】
複雑なネットワーク化システムの開発は、帰納的過程を有する系統的過程と、コンピュータにより支援されたツールの使用を前提とし、このツールにおいては、自動車メーカーのみならず下請業者もまた、開発すべき機能に対するすべての要求および境界条件を形式化し、すべての適用例および故障例における他の機能および周囲との多種の相互作用を分析し、且つ機能を、全体結合の信頼性へのその影響について評価することができる。複雑で且つネットワーク化されたシステムの開発に対して、自動車部門においても、設定モデルとしてＶモデルが確立されている。Ｖモデルは、機能開発に対する活動および経過の全体が１１の過程に分類されるように形成されている（図１）。
【０００８】
Ｖモデルは、仕様過程および設計過程の細分化および精細化を特徴とし、且つトップ・ダウン方式としてわかりやすく示される方法を表わす。これに対して、検証過程および確認過程はボトム・アップ方式である。この場合、品質の証明に対する本質的な要求および前提は、個々の過程に対する詳細な証明資料である。
【０００９】
経済的な車両開発に対する要求、複雑なシステム構成の解消および適切な資料作成を実行可能にするために、順序概念「カートロニク」（Ｃａｒｔｒｏｎｉｃ）（Ｔ．Ｂｅｒｔｒａｍ、Ｒ．Ｂｉｔｚｅｒ、Ｒ．ＭａｙｅｒおよびＡ．Ｖｏｌｋａｒｔ著「カートロニク（ＣＡＲＴＲＯＮＩＣ）−自動車制御装置におけるネットワーク化のためのオープン・アーキテクチュア」、デトロイト／ミシガン、Ｕ．Ｓ．Ａ．、ＳＡＥ９８０２００、１−９頁参照）が開発された。
【００１０】
過程列の第１の過程、即ち分析において、オブジェクト指向の基本的な考え方に基づいて開発された順序概念は、システム構成要素を、標準化論理インタフェースを有する機能ユニットに論理的に集約することを可能にする。したがって、従来相互にほぼ独立に作動していた自動車の個別システムを車両の範囲内の結合システムにネットワーク化することの記載は、モジュールとして拡張可能な機能アーキテクチュア、安全性アーキテクチュアおよびエレクトロニクス・アーキテクチュアに対する（メタ）モデル（変形モデル）を表わす。この自動車メーカーおよび下請業者の使用可能性の本質的な利点は、きわめて早い開発時点において既に、短い実習期間後に開発過程に関連するすべての要求をわかりやすく且つ論理的に記載できることである。
【００１１】
図式化されたモデルは、本質的な資料要素として、あらゆる開発過程の間に、すべての開発関係者間の情報交換を支援し、並びに開発終了後の保守および継続開発を支援する。この場合、通常のソフトウェア・エンジニアリングに補足して、自動車分野におけるメカトロニク・システム開発に対して、人的グループとして、次のものが支援しなければならない。即ち、車両メーカーは、システムの機能性に関する情報を必要とするユーザ、顧客並びに関係者として支援しなければならず、機械構造および電気技術の専門エンジニア並びに情報技術者は、メーカー側および下請業者側のメカトロニク構成要素の開発者として、並びに開発終了後にメカトロニク構成要素を修正ないし拡張し且つこのために全体システムまたはその一部の理解を必要とするメカトロニク構成要素の開発者として支援しなければならず、プロジェクト管理に関する組織的および経済的な細目、およびコスト計算および将来のプロジェクトおよび開発に関する情報を必要とする、開発者側および顧客側のマネジャー並びに特に車両のドライバは、システムの選択された機能性を信頼しなければならない特定のエンド・ユーザとして支援しなければならない。
【００１２】
分析過程の終了時および設計過程の開始時における本質的なステップは、カートロニク内で開発された仕様モデルをソフトウェア開発のための情報技術的設計に変換することである。この変換は情報密度の向上および作成されたカートロニク・モデルの意味的内容の拡張に寄与し、全体システム・アーキテクチュア内の部分システムを定義し、全体システムの実行の目標方向へのその透明性を向上させ、また割り当てられた開発に対する本質的な基礎およびメカトロニク・システムのテスト可能性を提供する。
【００１３】
ここで、市場で購入可能なソフトウェア開発ツールによるできるだけ広範囲の支援が得られるという背景下における、ＣＡＲＴＲＯＮＩＣ内で作成された仕様モデルから、標準化されたオブジェクト指向の表示への変換を説明する。このために必要な適切な記号を、オブジェクト管理グループ（ＯＭＧ）により国際的に標準化された、統一モデル化言語（ＵＭＬ）のオブジェクト指向の言語基準が示している。
【００１４】
以下に、機能アーキテクチュアのためのＣＡＲＴＲＯＮＩＣに基づく構造要素および形式化された構造化規則並びにモデル化規則の概要を説明する。さらに、高い抽象レベルにある、駆動装置構成要素に対して細分化された全体車両の機能アーキテクチュアを紹介する。これから出発して、最初にモデル化の理論的基礎の説明を行ってから、この章のさらに先で、ＵＭＬによるオブジェクト指向の記号が使用された要素を説明する。ＣＡＲＴＲＯＮＩＣに基づくこのモデルに対する方式を一例で説明する。
【００１５】
今日の車両内に既に存在する、システム結合に対する一例は、駆動滑り制御である。駆動滑り制御は、駆動滑り制御のための制御装置と、駆動トルクを制御するための機関管理に対する制御装置との通信によりはじめて可能となる。
【００１６】
ＣＡＲＴＲＯＮＩＣは、車両の操作および制御システムに対する順序概念である。この概念は、取り決められ且つ形式化された構造化規則およびモデル化規則に基づく、「機能」、「安全性」および「エレクトロニクス」に対する、モジュール化され且つ拡張可能なアーキテクチュアを含む。
【００１７】
ここで、構造体系（規則）のみならず、それのある具体的な構造への変換もまた、１つのアーキテクチュアのもとにあると理解される。機能アーキテクチュアは車両内に現われるすべての操作および制御課題を含む。システム結合の課題は論理的構成要素に割り当てられ、構成要素のインタフェースおよび構成要素の協調が特定される。安全性アーキテクチュアは、システム結合の確実な作動を保証する要素だけ、機能アーキテクチュアを拡張する。最後に、エレクトロニクスに対しては、必要に応じて最適なハードウェア・トポロジーでシステム結合が形成されるように、体系が与えられる。
【００１８】
アーキテクチュアの要素は、一方では構成要素および通信連絡であり、他方では構造化規則およびモデル化規則である。構造化の範囲内で、構成要素から構成された１つのシステムから、通信連絡を介して相互に作用し合う全体に対して会話が行われる。用語「構成要素」は、必ずしも構造部分の意味における物理的なユニットを意味せず、機能ユニットと理解される。順序概念において、３つの異なるタイプの構成要素（コンポーネント）が区別される。
【００１９】
主として調整および配分の課題を有する構成要素、
主として作動および実行の課題を有する構成要素、および
ただ情報を発生し且つ提供するのみの構成要素。
【００２０】
通信連絡においては、「指令（回答付）」、「問い合わせ（指針付）」および「要求」が区別される。指令は、実行すべき義務を表わし、指令を満たすことができない場合、指令受取部は、満たすことができない理由を表わす回答を指令伝送部に与える。問い合わせは、指令を実行するための情報を供給するように働く。構成要素が問い合わされた情報を提供できない場合、構成要素は問い合わせを出した構成要素に指針を与える。要求は、機能が他の構成要素により実行されることの「希望」を表わす。しかしながら、要求に対してはそれを満たすべき義務は課せられてなく、このことは、例えば要求が競合した場合に考慮される。次の表は、構造要素を一覧表で示している。
【００２１】
【表１】
2004504972.tif 000003
構造化規則は、全体車両のアーキテクチュア内において可能化された通信連絡を表わす。通信連絡を、同じ抽象レベルで規定する構造化レベルと、所定の境界条件を考慮して、より高いレベルおよびより低いレベルで規定する構造化規則とは区別される。さらに、構造化規則は、１つのシステムからその細分化内の他のシステムへの通信連絡の延長を明確にする。
【００２２】
モデル化規則は、現われる多種類の特定課題を解決するために構成要素および通信連絡を集約するパターンを含む。このとき、このパターン、例えばエネルギー管理は、車両構造内の種々の位置において再使用することができる。
【００２３】
構造化規則およびモデル化規則に従って開発された構造は次の特徴を有している。
□すべての抽象レベル上での、取り決められ且つ統一的な構造化規則およびモデル化規則、
□階層指令流れ、
□個々の構成要素の高い自己責任、
□操作要素、センサおよび評価装置は等価の情報提供部であり、および
□各構成要素を、残りの構成要素に対して、必要に応じて見えるようにするが、できるだけ見えないようにするカプセル化。
【００２４】
図２はアーキテクチュア特徴および可能化された通信連絡の一例を示す。これは詳細に示され、しかも図を簡単にするために、指令、問い合わせ、および要求のみが示されているにすぎないが、次のそれぞれを可能にする連絡が示されている。
【００２５】
−　駆動装置の外枠から、同時に調整部でもある入口構成要素としての駆動装置調整部に延長された指令「ｍｏｍｅｎｔ＿ｇａ（トルクを変速機出口において供給する）」、
−　駆動装置調整部から、機関、コンバータおよび変速機への指令「ｍｏｍｅｎｔ＿ｍａ（トルクを機関出口において供給する）」、「ｓｔｅｌｌｅＫｒａｆｔｓｃｈｌｕｓｓ（力伝達結合の形成）」および「ｅｉｎｌｅｇｅｎＧａｎｇ（１つのギヤを投入する）」、
−　変速機制御盤から駆動装置調整部への要求「！ｒＧａｎｇ（後退ギヤ）」、
−　変速機および環境への問い合わせ「？ｚｕｓｔａｎｄ（状態）」および「？ｌｕｆｔｄｒｕｃｋ（環境の大気圧）」、並びに
−　駆動装置の外枠への問い合わせ「？ｇａｎｇ（後退ギヤかどうか）」および「？ｄｒｅｈｚａｈｌ（回転速度か）」、この外枠は、問い合わせを、さらに該当構成要素としての機関および変速機へ延長させる。
【００２６】
ソフトウェアの一般的なライフサイクルにおいて、厳密な順序で実行されるべき過程として、問題分析と、システム仕様と、設計と、構成要素テスト、全体テストおよび導入の実行と、ソフトウェア・システムの運用および保守とが区別されている。実際に、このように厳密な順序で行われる開発過程は理想ケースであって、必ずしもこのように行われる必要はない。理論的に明確な境界点が、オーバラップしたり、または場合により種々の幅だけ先行したり、開発過程におけるあらゆるシステム開発協力者の側のノウハウが同時にはるかに先行したりする。オブジェクト指向の方法は、最初から既に高い再使用可能性で開発された、ないし存在する部分および概念が過程を超えて先行することを可能にする。これはコンピュータにより支援された図式記号の使用により本質的に容易となる。オブジェクト指向のソフトウェア開発において使用される種々の体系的方法は、それぞれの方法に対して開発された特殊な図式記号を含む。ＵＭＬは、工業的ソフトウェア開発においてたいていの場合使用される３つの方法、即ちＧｒａｇｙ　Ｂｏｏｃｈから名付けられたＢｏｏｃｈ法、Ｊａｍｅｓ　Ｒｕｍｂａｕｇｈにより開発されたオブジェクト・モデル化法（ＯＭＴ）並びにＩｖａｒ　Ｊａｃｏｂｓｏｎにより開発されたオブジェクト指向ソフトウェア・エンジニアリング（ＯＯＳＥ）から出発している。この場合、ＵＭＬは他の新しい一般的な方法を示すのではなく、種々の視点でモデルを構築するためのメタモデル（変形モデル）を示す（図３）。ＵＭＬは、統一的なシンタクス（構文法）および明確に定義されたセマンティク（意味論）を有する図式記号および補足的に表にした記号および文章記号を示す。
【００２７】
開発されたＵＭＬモデルは特に開発過程に参加した人が明確に解釈可能であり、且つ本質的な利点として、
−　国際基準の使用、
−　可能な限りメーカーとは無関係な、ツールにより支援された方式、
−　技術者に適したトップ・ダウン方式の基本としてのソフトウェアのライフサイクル・モデルを課題とすることなく、ソフトウェア開発における分析過程および設計過程の一般的な順序への固執に対する柔軟性、
−　論理レベルにおける最終的に使用されたプログラム言語からのできるだけ十分な独立性、
−　分析、設計および実行の間の一貫性の保持、並びに
−　同時に行われるボトム・アップのリバース・エンジニアリング方式の可能性、
を提供する。
【００２８】
分析過程において準形式的に構造化された仕様としてＣＡＲＴＲＯＮＩＣモデルが発生し、これはメカトロニク・システムを提供するものである。このモデルは、車両システム構造から機能的論理概念をオブジェクト指向で抽象化することを示す。はるかに有力なＵＭＬモデルに適切に変換することにより、同時に分析過程とデザインおよび設計過程との入替えが行われる。この場合、ソフトウェア・システムの全体アーキテクチュアに対する基本が設けられ、複雑性を低減ないし抑制するための部分システムが定義され、且つこれらの間の明確なインタフェースが使用される。設計過程が進んだ段階で、さらに詳細部を追加することにより過程が実行の方向に進むことになる。デザインないし設計過程の目的は、データ構造およびアルゴリズム構造並びにその有効性の確認を含めて、基礎となる論理データ・モデルの定義による、システム構成要素、その構造およびインタフェースの特定にある。複雑性は抽象化により解消することができ、この場合、全体の簡易化のみならず一覧性も保証されなければならない（大きな形での構造化）。後の段階において、同様に、構造化は、要求されたシステムの性能特性の最適化を目的として、アルゴリズム的形式化における適切なプログラム要素の選択に関係することになる（小さな形での構造化）。実行過程の目的は、論理データ・モデル、システム・アーキテクチュアおよびアルゴリズムを、自動車内の個々の制御装置および通信ネットワークのために翻訳可能なプログラム・コードに変換することにある。
【００２９】
実施例
以下に、カートロニク要素のＵＭＬ要素への変換を図４に示した部分図により説明する。この場合、ＣＡＲＴＲＯＮＩＣ規則をできるだけ完全に支持すること、オブジェクト指向の基本的な考え方を保持すること、およびここでＣＡＲＴＲＯＮＩＣモデル作成者に対して十分理解しやすく且つ十分透明にさせること、並びに後の作業ステップに対して必要なすべての情報を受け取り且つ表示できることが本質的な考慮である。
【００３０】
図４は、ＣＡＲＴＲＯＮＩＣ構成要素、即ち「環境」、「駆動装置」、「車両調整部」および「搭載電源」を示す。これらの構成要素間に次の通信連絡が存在する。車両調整部は、駆動装置に実際の回転速度「？ｄｒｅｈｚａｈｌ」について問い合わせ、ないし駆動装置に変速機出口におけるトルク「ｍｏｍｅｎｔ＿ｇａ」を提供することを指令する。駆動装置は、情報提供部としての環境に実際の大気圧「？ｌｕｆｔｄｒｕｃｋ」について問い合わせ、且つ搭載電源の構成要素から電気的出力「！ｅｌ＿Ｌｉｓｔｕｎｇ」を要求する。
【００３１】
オブジェクト指向の用語内のクラスは、一般に、同じタイプのオブジェクトの一般化（型）であり、より高い抽象レベルにおいては構成要素ないしクラスは材料対象物であることは少なく、たいていは抽象的物体または機能ユニットである。オブジェクト（一般に対象物）は、性質および特性を有するクラスからのサンプルである。オブジェクト指向のモデル化においては、クラスを探すときにしばしば使用される入口は名詞を探すことであり、その理由は、名詞は言語において一般にオブジェクト・グループの一般化を形成するからである。形容詞は性質を表わし且つ一般に付加語としてモデル化される。一方で、オペレーションはオブジェクトの特性を変換し、これは動詞に対応する。したがって、ＣＡＲＴＲＯＮＩＣ構成要素をＵＭＬクラスないしＵＭＬオブジェクトとして表わすことが理解される。
【００３２】
ステレオタイプ《ｈｕｅｌｌｅ（外枠）》、《ｉｎｆｏｒｍａｔｉｏｎｓｇｅｂｅｒ（情報提供部）》、《ｋｏｏｒｄｉｎａｔｏｒ（調整部）》および《ｏｐｅｒａｔｏｒ（オペレータ）》を介して構成要素としてのクラスが上記のカテゴリーに割り当てられる。図４からの環境の構成要素は、例えば名称「環境」およびステレオタイプの《ｉｎｆｏｒｍａｔｉｏｎｓｇｅｂｅｒ（情報提供部）》を有するクラスとして表わされる。
【００３３】
３つのＣＡＲＴＲＯＮＩＣ通信タイプ、即ち「指令」、「問い合わせ」および「要求」は他の構成要素に「何かをすること」を要求し、したがって、これらはオブジェクト指向のモデル化においては情報と解釈され、およびステレオタイプ《ａｕｆｔｒａｇ（指令）》、《ａｂｆｒａｇｅ（問い合わせ）》および《ａｎｆｏｒｄｅｒｕｎｇ（要求）》によりＵＭＬオペレーションとしてモデル化される。ＣＡＲＴＲＯＮＩＣ指令「ｍｏｍｅｎｔ＿ｇａ（変速機出口トルク）」から、駆動装置クラスのＵＭＬオペレーション《ａｕｆｔｒａｇ》ｍｏｍｅｎｔ＿ｇａ（《指令》変速機出口トルク）が形成され、この構成要素へのＣＡＲＴＲＯＮＩＣ問い合わせ「？ｄｒｅｈｚａｈｌ（回転速度）」から、ＵＭＬオペレーション《ａｂｆｒａｇｅ》ｄｒｅｈｚａｈｌ（《問い合わせ》回転速度）が形成され、並びに環境の構成要素へのＣＡＲＴＲＯＮＩＣ問い合わせ「？ｌｕｆｔｄｒｕｃｋ（大気圧）」から、環境クラスのＵＭＬオペレーション《ａｂｆｒａｇｅ》ｌｕｆｔｄｒｕｃｋ（《問い合わせ》大気圧）が形成される。図５に示した図において、駆動装置、搭載電源および環境のクラス内の二重線は、それまでまだ付加語が存在していないことを記号で表わしている。車両調整部クラスにおいては、場合により存在する付加語またはオペレーションの図示は必要がないので、クラスの宣言領域のみが示されている。これは全体図を与えている。ＣＡＲＴＲＯＮＩＣ回答はＵＭＬオペレーションの戻しパラメータとしてモデル化され、したがって、変換規定においては、独立のＵＭＬオペレーションとして明示的にモデル化されていない。
【００３４】
所定のアクセス制御およびアクセス・チェックを目的とした個々の構成要素のカプセル化は、ＵＭＬオペレーションに対する明示的なＵＭＬインタフェースによりモデル化される。指令のためのインタフェース並びに問い合わせおよび要求のためのインタフェースとは、２つのステレオタイプ《ｉｎｔｅｒｆａｃｅＡｕｆｔｒａｇ（指令インタフェース）》と《ｉｎｔｅｒｆａｃｅ（インタフェース）》とにより区別される。これにより、指令に対して適用される、「一人シェフ（料理人）原理」に従った、より厳密なアクセス規則が明示的にモデル化される。図６はこれをクラス《ｏｐｅｒａｔｏｒ（オペレータ）》駆動装置の例で示している。
【００３５】
図７は、より細分化されたＣＡＲＴＲＯＮＩＣ構成要素を駆動装置の構成要素の例で示しているが、ここでは、機関、駆動装置調整部および変速機の３つの部分構成要素のみを有していることが図２と異なっている。ＵＭＬ集合は関係「の部分である」を表現し、したがってＣＡＲＴＲＯＮＩＣ細分化に正確に対応している。ＵＭＬ構成は、ＣＡＲＴＲＯＮＩＣの理解と同様に、ＵＭＬ集合の特殊な場合として、部分構成要素は集合体がなければ存続しないことを表わしている。ＵＭＬ集合体および論理的総合体としてのＵＭＬ集合体およびＵＭＬ構成は、取得することはできるがそれ自身実行できない情報を対応部分構成要素に（自動的に）伝送する（ＣＡＲＴＲＯＮＩＣの外枠の性質に類似）。図８は、一部細分化されたＵＭＬクラス《ｈｕｅｌｌｅ（外枠）》駆動装置を、ＵＭＬクラス、即ち機関、駆動装置調整部および変速機のＵＭＬ構成として示す。
【００３６】
高い抽象レベルにある大きく且つ複雑なＣＡＲＴＲＯＮＩＣ構成要素は、モデル化と同様に、ＵＭＬクラスを介してＵＭＬサブ・システムとしても変換することができる。ＵＭＬサブ・システムはインタフェースを有してもよいＵＭＬパケットの特殊形状であるので、有効なカプセル化および大きな形での構造変換を保証するのに適している。この場合、同様に、指令ないし問い合わせおよび要求に対する別々のインタフェースは、以下に挙げる方式を保持し続けている。サブ・システムとその中に含まれているモデル要素との間の、集合または構成の形の結合は、サブ・システム・インタフェースから、直接、対応する構成要素への情報の延長伝送を可能にする。図９に示されているように、インタフェース、ここでは《ｉｎｔｅｒｆａｃｅＡｕｆｔｒａｇ（指令インタフェース）》ＩＡ＿駆動装置は、内部要素、この場合《ｉｎｔｅｒｆａｃｅＡｕｆｔｒａｇ（指令インタフェース）》ＩＡ＿駆動装置調整部のインタフェースにより提供することができる。
【００３７】
ＣＡＲＴＲＯＮＩＣモデルの継続的な開発は、構成要素の変更可能性および交換可能性を要求する。上記の部分図内に示した、個々のＣＡＲＴＲＯＮＩＣ要素のＵＭＬへの変換のほかに、継続的な開発過程においてステップおよび過程が支援されなければならない。この場合、実際に、以下に示す種々の過程ステップの混合形式が発生する。これらは、要素の細分化、抽象化、補充並びに消去から構成されている。
【００３８】
ＣＡＲＴＲＯＮＩＣ構成要素の細分化において、ＣＡＲＴＲＯＮＩＣ規則化装置により、固有の論理機能をもたない外枠が発生し、存在する既知のすべての機能性は発生した部分構成要素に配分される。細分化されるべき構成要素のカプセル化ないしインタフェースは、外部に対する特性を変化させないために、完全に外枠内に保持されていなければならない。これが、例えば図６において、駆動装置クラスのオペレーション「ｍｏｍｅｎｔ＿ｇａ（変速機出口トルク）」および「ｄｒｅｈｚａｈｌ（回転速度）」である。図１０は細分化による新しいＵＭＬクラスを示す。ここでは、クラス、即ち機関、駆動装置調整部および変速機に細分化され、並びに追加オペレーション《ａｕｆｔｒａｇ》ｍｏｍｅｎｔ＿ｍａ（《指令》機関出口トルク）、《ａｎｆｏｒｄｅｒｕｎｇ》ｒＧａｎｇ（《要求》後退ギヤ）および《ａｕｆｔｒａｇ》ｅｉｎｌｅｇｅｎＧａｎｇ（《指令》ギヤ投入）に細分化されている。既に空になっているオペレーション領域と、並びにステレオタイプの《ｈｕｅｌｌｅ（外枠）》内の変化とを有する駆動装置クラスの図示には注意すべきである。駆動装置構成要素から《ｉｎｆｏｒｍａｔｉｏｎｓｇｅｂｅｒ（情報提供部）》環境への、機関構成要素の《ａｂｆｒａｇｅ》ｌｕｆｔｄｒｕｃｋ（《問い合わせ》大気圧）は、結合の形の２つの構成要素（両方は相互に通じ合っていなければならない）間の連絡を介して、並びに環境の対応インタフェースへの機関の依存性を介してモデル化される。これはすべてのＣＡＲＴＲＯＮＩＣ通信連絡に対して同様に適用される。ＵＭＬクラス相互間のすべての連絡の明示的なモデル化は、各々のインタフェースへのすべてのアクセスを介して完全な一覧の形に自動的に形成される。
【００３９】
抽象化過程は、構造化された複雑な構成要素構造を、その外枠構成要素およびインタフェースにより、コンパクトで見やすく表示するために必要且つ有効である。抽象化過程において、詳細図からの情報は失われてはならず、且つ種々の構成要素間の関数関係は、できるだけその他の情報を付加することなく変換されなければならない。図１０において、細分化されたＵＭＬ集合体「駆動装置」を抽象化するとき、図６に示した駆動装置構成要素とは異なり、「空の」クラスが残っている（図１１）。しかしながら、この場合、駆動装置および環境の部分要素間の関係がわかりにくいということが問題である。したがって、ＵＭＬモデルは、ＣＡＲＴＲＯＮＩＣ機能アーキテクチュアに追加して、構成要素即ち駆動装置および環境の間に、人為的にセットされた結合および従属性を必要とする。モデル化ツールを使用するとき、この問題点は、例えば対応する付加語により考慮することができる。
【００４０】
要素の最も簡単な交換方式は同じ機能性との交換であり、この交換においては、外部に対して明らかな、名前、インタフェースまたは連絡の変化なしに、１つの構成要素の内部でのみ修正が行われる（図１２）。
【００４１】
１つの構成要素が、名前、存在する連絡およびそれの古い機能性を保持しているが、新しい機能性、したがって新しいインタフェース・オペレーションだけ拡張されたとき、拡張された機能性との交換が存在する（図１３）。
【００４２】
交換において、１つの構成要素の内部要素が、他の構成要素への新しい連絡が必要とされるように修正された場合、変更された連絡との交換が行われる。これは、例えば情報が追加的に問い合わされる場合である。この場合、構成要素の名前およびインタフェースは不変のままである（図１４）。
【００４３】
脱落する機能性と交換したとき、インタフェース内の個々の機能ないしオペレーションは消失する。したがって、本来の消去過程の前に、全体モデルの他の構成要素が、消去されるべき要素をもはや使用できないようにするために、（自動化された）一貫性の有無の検査が行われなければならない。
【００４４】
１つの構成要素の消去は、脱落する機能性との交換の特殊な形とみなすことができる。この場合、そのオペレーションの反復脱落により、存在するクラスは、「空の」クラスに移行される。
【００４５】
即ち、自動車内メカトロニク・システムのモデル化方法および装置は、オブジェクト・ベースの順序概念の範囲内で、統一モデル化言語への変換として表わされる。これは、オブジェクト指向ソフトウェア開発過程における分析過程とデザインないし設計過程との間の本質的な結合要素を示す。そのクラスないしオブジェクトとしての構成要素および外枠と、その通信連絡としての指令（回答付）、問い合わせ（指針付）および要求とを有するＣＡＲＴＲＯＮＩＣの要素は、例に示すように、全体規則化装置からの本質的な規則と共に提供されている。このモデル化要素に対して、ＵＭＬ構成への変換規定が示される。外枠を含むＣＡＲＴＲＯＮＩＣ構成要素は、ステレオタイプ《ｋｏｏｒｄｉｎａｔｏｒ（調整部）》、《ｏｐｅｒａｔｏｒ（オペレータ）》、《ｉｎｆｏｒｍａｔｉｏｎｓｇｅｂｅｒ（情報提供部）》および《ｈｕｅｌｌｅ（外枠）》を有するＵＭＬクラスないしオブジェクトに変換される。ＣＡＲＴＲＯＮＩＣ通信連絡、即ち問い合わせおよび要求は、ステレオタイプ《ａｂｆｒａｇｅ（問い合わせ）》および《ａｎｆｏｒｄｅｒｕｎｇ（要求）》を有するＬＭＬオペレーションとして、ステレオタイプの《ｉｎｔｅｒｆａｃｅ（インタフェース）》を有するインタフェース内で供給され、およびすべての指令オペレーションは、ステレオタイプ《ｉｎｔｅｒｆａｃｅＡｕｆｔｒａｇ（指令インタフェース）》を有するインタフェース内でステレオタイプの《Ａｕｆｔｒａｇ（指令）》により表わされる。細分化された構成要素内に入り込んだ情報は、自動的に、構成連絡を介してそれぞれ付属の部分構成要素に伝送される。指令伝送部と指令受取部との間の階層化されていない通信連絡に対しては、これらの間に結合がモデル化され、且つ指令伝送部から指令受取部のインタフェースへ、従属性連絡がモデル化される。したがって、構成要素のカプセル化は、２つの別々のインタフェースを介して、暗示的な付属性連絡としての構成を介して、および従属性の表示を介して保証される。開発過程内で発生する、構成要素の細分化過程、抽象化過程、交換過程および消去過程に対しては、市場で購入可能なソフトウェア開発ツールを使用する方式が挙げられる。
【図面の簡単な説明】
【図１】
図１は、システム開発用のＶモデルを示す。
【図２】
図２は、アーキテクチュア特徴および可能にされた通信連絡の例を示す。
【図３】
図３は、ＵＭＬモデルへの変換を示す。
【図４】
図４は、ＣＡＲＴＲＯＮＩＣ要素のＵＭＬ要素への変換の部分図を示す。
【図５】
図５は、ＵＭＬオペレーションを示す。
【図６】
図６は、ＵＭＬオペレーションをクラス《ｏｐｅｒａｔｏｒ（オペレータ）》駆動装置の例で示す。
【図７】
図７は、細分化されたＣＡＲＴＲＯＮＩＣ構成要素を駆動装置構成要素の例で示す。
【図８】
図８は、一部細分化されたＵＭＬクラス《ｈｕｅｌｌｅ（外枠）》駆動装置を示す。
【図９】
図９は、インタフェース《ｉｎｔｅｒｆａｃｅＡｕｆｔｒａｇ（指令インタフェース）》ＩＡ＿Ａｎｔｒｉｅｂを示す。
【図１０】
図１０は、細分化による新しいＵＭＬクラスを示す。
【図１１】
図１１は、駆動装置の構成要素内の「空の」クラスを示す。
【図１２】
図１２は、構成要素の交換方式を示す。
【図１３】
図１３は、拡張された機能性との交換を示す。
【図１４】
図１４は、構成要素の内部要素の交換において、他の構成要素との新しい連絡が必要とされる例を示す。
【図１】
2004504972.tif 000004
【図２】
2004504972.tif 000005
【図３】
2004504972.tif 000006
【図４】
2004504972.tif 000007
【図５】
2004504972.tif 000008
【図６】
2004504972.tif 000009
【図７】
2004504972.tif 000010
【図８】
2004504972.tif 000011
【図９】
2004504972.tif 000012
【図１０】
2004504972.tif 000013
【図１１】
2004504972.tif 000014
【図１２】
2004504972.tif 000015
【図１３】
2004504972.tif 000016
【図１４】
2004504972.tif 000017
【国際公開パンフレット】
2004504972.tif 000018
2004504972.tif 000019
2004504972.tif 000020
2004504972.tif 000021
2004504972.tif 000022
2004504972.tif 000023
2004504972.tif 000024
2004504972.tif 000025
2004504972.tif 000026
2004504972.tif 000027
2004504972.tif 000028
2004504972.tif 000029
2004504972.tif 000030
2004504972.tif 000031
2004504972.tif 000032
2004504972.tif 000033
2004504972.tif 000034
2004504972.tif 000035
2004504972.tif 000036
2004504972.tif 000037
2004504972.tif 000038
2004504972.tif 000039
2004504972.tif 000040
2004504972.tif 000041
2004504972.tif 000042
2004504972.tif 000043
2004504972.tif 000044
2004504972.tif 000045
2004504972.tif 000046
2004504972.tif 000047
2004504972.tif 000048
【国際公開パンフレット（コレクトバージョン）】
2004504972.tif 000049
2004504972.tif 000050
【手続補正書】
【提出日】平成14年1月22日(2002.1.22)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】特許請求の範囲
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
メカトロニク・システムが、構成要素間に、問い合わせ、要求および指令のような所定の通信連絡が存在する複数の前記構成要素からなる、自動車内メカトロニク・システムのモデル化方法において、
変換規定が設けられており、該変換規定により、システムの構成要素および連絡が、オブジェクト指向のモデル化言語、好ましくはＵＭＬ言語の構成に変換されること、
を特徴とする自動車内メカトロニク・システムのモデル化方法。
【請求項２】
前記変換規定は、外枠を含む構成要素が、ステレオタイプ《ｋｏｏｒｄｉｎａｔｏｒ（調整部）》、《ｏｐｅｒａｔｏｒ（オペレータ）》、《ｉｎｆｏｒｍａｔｉｏｎｓｇｅｂｅｒ（情報提供部）》および《ｈｕｅｌｌｅ（外枠）》を有するＵＭＬクラスないしオブジェクトに変換され、通信連絡、即ち問い合わせおよび要求が、ステレオタイプ《ａｂｆｒａｇｅ（問い合わせ）》および《ａｎｆｏｒｄｅｒｕｎｇ（要求）》を有するＵＭＬオペレーションとして、ステレオタイプ《ｉｎｔｅｒｆａｃｅ（インタフェース）》を有するインタフェース内で供給され、且つすべての指令オペレーションが、ステレオタイプ《ｉｎｔｅｒｆａｃｅＡｕｆｔｒａｇ（指令インタフェース）》を有するインタフェース内でステレオタイプ《ａｕｆｔｒａｇ（指令）》により表わされることからなることを特徴とする請求項１の方法。
【請求項３】
構成要素間に、問い合わせ、要求および指令のような所定の通信連絡が存在する複数の前記構成要素からなる自動車内メカトロニク・システムのモデル化装置において、
変換規定が設けられており、該変換規定により、システムの構成要素および連絡が、オブジェクト指向のモデル化言語、好ましくはＵＭＬ言語の構成に変換されること、
を特徴とする自動車内メカトロニク・システムのモデル化装置。
【国際調査報告】
2004504972.tif 000051
2004504972.tif 000052
2004504972.tif 000053
2004504972.tif 000054
2004504972.tif 000055
2004504972.tif 000056