(57)【要約】【課題】  本発明は，車両の駆動アグリゲート（３００）を制御するための制御装置（１００）とコンピュータプログラムに関する。伝統的にこの種の制御装置（１００）内には，例えば機能ユニット駆動，エンジンコーディネータ，診断マネージャなど，多数の機能ユニットが設けられている。特に制御装置によって制御すべき駆動アグリゲートを交換する場合に，機能ユニットのすべてまたは大部分ではなく，新しい駆動アグリゲートにとって重要な機能ユニットのみを交換すれば済むようにするために，本発明によれば，これらの機能ユニットをモジュール化することが提案される。このモジュール化においては，特に，ハードウェアを制御装置１００のモジュールと通信することができるように，制御装置のハードウェアの独立したプログラミングを可能にする機能ユニットが統合される。
2006518436.tif 000002
【特許請求の範囲】
【請求項１】
制御装置（１００）と駆動アグリゲート（３００）との間に接続されているセンサ／アクチュエータ構成（２００）を用いて，車両の駆動アグリゲート（３００），特に内燃機関を制御するための，少なくとも１つのプロセッサ（１００ａ−１）と少なくとも１つのメモリ素子（１００ａ−２）を有する制御装置（１００）であって：
前記メモリ素子（１００ａ−２）内に格納される多数の機能ユニット間の通信によって制御が行われ，
１つのモジュールのデジタル信号を他のモジュールの信号に対応づける信号対応づけ層（ＳＺＳ＝ＨＡＬ）を介して，第３のハードウェア遠位のモジュール（ＤＥ）と接続される第２のハードウェア近位のモジュール（ＣＯ）が設けられ，
前記ハードウェア遠位とハードウェア近位はプロセッサ上で関連することを特徴とする，制御装置。
【請求項２】
第１のモジュール（ＡＳＷ）が含まれ，前記第１のモジュール内には，物理レベルでユーザの要求に応じて駆動アグリゲートを調節するために用いられる機能ユニットが統合されていることを特徴とする，請求項１に記載の制御装置。
【請求項３】
第２のモジュール（ＣＯ）は，その中に，ハードウェアが制御装置（１００）のモジュールと通信可能にしつつ，制御装置のハードウェアの独立したプログラミングを可能にし，かつモジュール内の機能ユニットの機能の処理を時間的に調整する機能ユニットが統合され，
第３のモジュール（ＤＥ）は，その中に，センサ／アクチュエータ構成の個々のセンサまたはアクチュエータ間で制御装置の残りのモジュールと通信を可能にしつつ，使用されるセンサ／アクチュエータ構成（３００）を制御装置（１００）に独立して適合することを可能にする機能ユニットが統合され，
その場合に前記モジュール（ＣＯ，ＤＥ）間に，モジュールをまたがる通信のためのモジュールインターフェイス（Ｍ１…Ｍ５）が設けられていることを特徴とする，請求項１に記載の制御装置。
【請求項４】
第１のモジュール（ＡＳＷ）が：
−所定のタイプの駆動アグリゲート（３００）に対して固有ではない機能ユニットがその中に統合される，車両コンポーネント（ＶＦ）と；
−所定のタイプの駆動アグリゲート（３００）に対して固有である機能ユニットがその中に統合される，駆動アグリゲートコンポーネント（ＥＦ）と；
を有していることを特徴とする，請求項２と３に記載の制御装置（１００）。
【請求項５】
第２のモジュール（ＣＯ）が：
−基礎となるサービスを提供し，あるいは表し，他の機能ユニットへアクセスすることが可能な機能ユニットをその中に統合する，インフラ構造コンポーネント（ＩＳ）と；
−ハードウェアが制御装置（１００）のモジュール（ＡＳＷ，ＣＯ，ＤＥ，ＣＤ）と通信できるよう，制御装置（１００）のハードウェア（１００ａ）の独立したプログラミングを可能にする機能ユニットがその中に統合される，ハードウェアカプセルコンポーネント（ＨＷＥ）と；
を有していることを特徴とする，請求項１から４のいずれか１項に記載の制御装置（１００）。
【請求項６】
インフラ構造コンポーネント（ＩＳ）が，機能ユニットサービスライブラリ（ＩＳ−１），シーケンス制御（ＩＳ−２），診断マネージャ（ＩＳ−３）および／または監視コンセプト（ＩＳ−４）を有していることを特徴とする，請求項５に記載の制御装置（１００）。
【請求項７】
制御装置（１００）は，第４のモジュール（ＣＤ）を有しており，
前記第４のモジュール内に，制御装置への複雑なインターフェイスを有する特殊なセンサ／アクチュエータ構成を第１のモジュールによって直接駆動することを可能にする機能ユニットがまとめられていることを特徴とする，請求項１から６のいずれか１項に記載の制御装置（１００）。
【請求項８】
機能ユニット，コンポーネントおよび／またはモジュールおよびそれらの間のインターフェイスが，少なくとも部分的にコンピュータプログラムとして形成されていることを特徴とする，請求項１から７のいずれか１項に記載の制御装置（１００）。
【請求項９】
機能ユニット，コンポーネントまたはモジュールをマッピングし，駆動アグリゲートを制御するためそれらの間の通信を実現する，のに適したプログラムコードを有する，車両の駆動アグリゲート（３００）を制御するための請求項１−７のいずれか１項に記載の制御装置（１００）用のコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は，駆動アグリゲート，特に車両の内燃機関，を制御するための制御装置とコンピュータプログラムに関する。
【背景技術】
【０００２】
この種の制御装置と付属のコンピュータプログラムは，基本的な従来技術において知られている。図９は，この種の既知の制御装置を示すものであって，その場合に参照符号１００ａは制御装置１００のハードウェアを，そして参照符号１００ｂはソフトウェアを表している。制御装置１００のハードウェアは，少なくとも１つのプロセッサ１００ａ−１と少なくとも１つのメモリ素子１００ａ−２を有している。ソフトウェア１００ｂは，通常，メモリ素子１００ａ−２内に格納されている。ソフトウェア１００ｂは，従来技術においては，通常複数の機能ユニットＶＦ−１，ＥＦ−３，ＩＳ−２，ＨＷＥ−１，ＨＷＥ−３およびＶＦ−３を有しており，それらは駆動アグリゲート３００を駆動する目的のために少なくとも散発的に相互に通信する。駆動アグリゲート３００の直接的な制御は，制御装置１００と駆動アグリゲート３００の間に接続されているセンサ／アクチュエータ構成２００を用いて行われる。
【０００３】
駆動アグリゲート３００を制御するための制御装置１００用のソフトウェア１００ｂ内の既知の機能ユニットは，例えば：
・機能ユニット駆動ＶＦ−１：これは機械的エネルギのソースを管理し，機能ユニット車両コーディネータからの指示による基準に従って，車両の推進や隣接アグリゲートの供給のための，駆動アグリゲートに対する目標トルクを制御する。
・機能ユニット車両コーディネータＶＦ−２：これは種々の，他の機能ユニットの協働に関する決定を行う。例えば，種々の他の機能ユニットが駆動アグリゲートによるそれぞれ異なるトルク量を調節することを要請した場合に，上記機能ユニット駆動が駆動アグリゲートにおいてどのようにトルクを調節すべきかを決定する。
・機能ユニット車両運動ＶＦ−３：これは，最適な走行安定性の保証に関して，車両の実際の運動を運転者の意図と比較する。それに属するのは，例えば，アクセルペダルとブレーキペダルの動作に基づいて運転者意図を評価することと，この運転者意図を電子的な安定化プログラムＥＳＰまたはアンチスリップ制御ＡＳＲのような安全システムの基準を用いて調整することである。
・機能ユニット走行状態量ＶＦ−４：これは，どの機能ユニットがこの走行状態を求めるかに拘わらず，例えばストップアンドゴー，登り坂走行など，実際の走行状態に関する情報を管理する。
・機能ユニットエンジンコーディネータＥＦ−１：エンジンコーディネータは，エンジンのすべての駆動状態を調整し，かつエンジン駆動状態に関する情報を制御のため提供する，という課題を有している。
・機能ユニットエンジントルク構造ＥＦ−２：この機能ユニットは，エンジンの他の機能ユニットからのトルク要請を算出，調整し，結果として生じるトルク変換に対する要請を求める，という課題を有している。
・アグリゲートポジション−マネージメントＥＰＭ：この機能ユニットは，駆動アグリゲートのクランク軸とカム軸の位置および回転数検出を実施する，という課題を有している。
・機能ユニットサービスライブラリーＩＳ−１：これは，一般に，様々な機能ユニットによって照会または利用される，極めて頻繁に使用される機能を準備する，という課題を有している。この機能ユニットは，これらの機能を中心で準備するので，それらを複数に分散して準備する必要がない，という利点を有している。
・機能ユニットシーケンス制御ＩＳ−２：これは，様々な機能ユニットの要請の時間的な処理を調整する。
・機能ユニット診断マネージャＩＳ−３：この機能ユニットは，例えば制御装置１００のハードウェア１００ａ内の故障を表す，エラー信号の編集を受け持つ。編集は，特にエラー信号の影響と，後でエラー信号の評価を行うことができるようにするための格納にある。
・機能ユニット監視コンセプトＩＳ−４：この機能ユニットは，特に制御装置のプロセッサの監視に用いられる。
・機能ユニット信号編集ＨＷＥ−１：これは，制御装置内に場合によっては発生している可能性のある，望ましくない信号変調に関するデジタル化アナログセンサ信号の排除（解決）を実施する。
・機能ユニットガスシステムＥＦ−３：これは，駆動アグリゲート３００に対して実際に提供される空気質量に関する情報を供給し，それが駆動アグリゲートに与える影響の範囲で所望の目標空気質量および／または排ガス品質を監視あるいは調節する，という主な課題を有している。この機能ユニットガスシステムは，特にディーゼル機関またはガソリン機関において使用される。
・機能ユニット噴射システムＥＦ−４：これは，燃料給送，噴射圧発生および噴射に必要なすべての機能を準備する。
【０００４】
これら既知の機能ユニットの詳細が，図９においては制御装置のソフトウェア１００ｂの内部に例示されている。しかしそれらは，すべてが一度に開発され，ソフトウェア１００ｂ内に実装されるのではなく，開発が続行される時間の経過の途中で，初めて逐次制御装置１００のソフトウェアに追加される。新しい機能ユニットを追加する場合に，従来は，新しい機能ユニットが，必要な限りにおいて，他のすべての機能ユニットと通信できることのみに注意して来た。従って時間の経過と共に，個々の機能ユニット間のインターフェイスの全体的な見通しが悪くなる事態が生じ，そのことが，特に，既知の機能ユニットを修正された機能ユニットと交換すること，または新しい機能ユニットをさらに追加することを，どんどん困難にしていった。このような困難性は特に，個々の機能ユニット間にすでにある関係を，システム全体またはその一部のみを変更する場合に，見通しが極めて難しいことによって生じる。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
この従来技術に基づいて，本発明の課題は，車両の駆動アグリゲートを制御するための既知の制御装置とコンピュータプログラムを，制御装置の個々の部分と特にそのソフトウェアの個々の部分が互いに独立して実現可能かつ交換可能であるように，展開することである。
【課題を解決するための手段】
【０００６】
この課題は，特許請求項１の対象によって解決される。それによれば，上述した既知の制御装置に対して，少なくとも３つのモジュールの形式によるモジュール化が行われ，その場合に第１のモジュール内には，物理レベルでユーザの要求に応答して駆動アグリゲートを調節するために用いられる機能ユニットがまとめられ，第２のモジュール内には，配置換えされたハードウェアが制御装置のモジュールと通信可能な方法で，制御装置のハードウェアの独立したプログラミングを可能にし，かつモジュール内の機能ユニットの機能の処理を時間的に調整する機能ユニットがまとめられ，第３のモジュール内には，構成の個々のセンサまたはアクチュエータ間で制御装置の残りのモジュールとの通信ができるように，使用されるセンサ／アクチュエータ構成を制御装置に個々に適合させることを可能にする機能ユニットがまとめられており，かつ，その場合にモジュール間にはモジュールにまたがる通信のためのモジュールインターフェイスが設けられている。
【０００７】
本発明の主旨における駆動アグリゲートは，内燃機関の代わりに，例えば電子駆動装置または燃料セル駆動装置を表すこともできる。
【０００８】
本発明の主旨におけるユーザは，例えば車両の運転者，立法者，車両下請け業者または車両生産者とすることができる。
【０００９】
本発明の主旨における物理レベルは，ハードウェアの特徴を抽象化したものを意味する。これは，物理レベル内では，その周囲へのセンサのインターフェイスに関して，例えば駆動アグリゲートの回転数のような物理的な変量のみが考察され，回転数を示す振幅といった，ハードウェア固有の電子信号形式でのハードウェア的な実現は考察されないことを，意味している。
【発明の効果】
【００１０】
権利請求されているモジュール化の本質的な利点は，個々のモジュールが簡単に交換可能であり，かつ互いに無関係に実現可能であることにある。その場合に，機能ユニットを個々のモジュールに分割することは，特に車両生産者の視点からおよび物理的な視点から有意義である。個々のモジュールの交換は，個々のモジュールの間で定められたモジュールインターフェイス内に，種々のモジュール内における機能ユニット間のすべての関係が考慮されていることによって，特に簡単である。それを越える関係は，機能ユニットのレベルではまだ存在し得るが，モジュールのレベルではもはや存在せず，従ってモジュールを交換する際に考慮する必要はない。
【００１１】
提案されているモジュール化は，特にコストと時間の節約と結びついている。他の制御装置ハードウェアまたは他のセンサ／アクチュエータ構成を使用する場合に，もはや制御装置のソフトウェア全体を交換または適合させる必要はなく，むしろ，該当するモジュールのみを交換すれば十分である。
【００１２】
第１の実施例によれば，好ましくは，第１のモジュールを車両コンポーネントと駆動アグリゲートコンポーネントに分割することが，提案される。第２の実施例によれば，第２のモジュールをインフラ構造コンポーネントとハードウェアカプセル，および，さらに選択的に，場合によっては通信コンポーネントにも分割することが，提案される。
【００１３】
上述した実施例について要約すると，個々のモジュールをコンポーネントに分割することは，モジュールの場合と同様に，コンポーネントの交換可能性を改良するために用いられることが，認められる。
【００１４】
好ましくはモジュール内部のコンポーネント間にも，迅速なデータ交換のためのインターフェイスが設けられている。それに対して異なるモジュールにおけるコンポーネント間の通信は，モジュールインターフェイスを介して行われる。上記コンポーネント自体も，それぞれ任意の数の機能ユニットに分割されている。インターフェイスは，これらの機能ユニットのレベルにも設けられているので，コンポーネント内の種々の機能ユニットは互いに通信することができる。異なるコンポーネントにおける機能ユニット間の通信は，コンポーネントインターフェイスを介して行われ，異なるモジュール内の機能ユニット間の通信は，モジュールインターフェイスを介して行われる。機能ユニット間およびコンポーネント間のインターフェイスについても，モジュールインターフェイスについて上述した説明の通り，すなわち，これらのインターフェイス内では機能ユニットまたはコンポーネント間の互いに対するすべての必要な関係が考慮されており，それぞれ他の関係は考慮する必要はない。上記によってモジュールだけでなく，コンポーネントまたは機能ユニットの簡単な交換可能性，すなわち，特に顧客の要求または新しいテクノロジーへの容易かつ複雑ではない適合がもたらされる。
【００１５】
個々のコンポーネントと個々のコンポーネント内にまとめられる機能ユニットおよびエレメントの課題の詳細な説明が，従属請求項の対象である。好ましくは，機能ユニット，コンポーネントおよび／またはモジュール並びにそれらに設けられたそれぞれのインターフェイスは，少なくとも部分的にコンピュータプログラムとして形成されている。コンピュータプログラムとして形成することは，修正要求に対するフレキシブルな変換を許し，制御装置のハードウェアの変更を行う必要はない。
【００１６】
上述した課題は，さらに，記載され，かつ権利請求される制御プログラムのためのコンピュータプログラムによっても解決される。このコンピュータプログラムの利点は，制御プログラムに関して上述した利点に相当する。
【００１７】
他の利点は，以下の説明から明らかにされる。説明には，全部で９図が添付されている。
【発明を実施するための最良の形態】
【００１８】
以下，図面を参照して本発明の実施例を詳細に説明する。
【００１９】
図１は，図９を参照して，車両の駆動アグリゲート３００，特に内燃機関を制御するための制御装置１００内の機能ユニットを本発明に従ってモジュール化することを示している。図９とは異なり，図１にはメモリ素子１００ａ−２の内容の構造のみが示されている。特に，センサ／アクチュエータ構成２００と駆動アグリゲート３００は，本発明の対象ではなく，従って以下においては詳細な説明を省略する。
【００２０】
本発明によれば，制御装置１００内の機能ユニットを４つの別々のモジュールにグループ化することが提案される。
【００２１】
第１のモジュールＡＳＷ内には，物理レベル上でユーザの意図に応答して駆動アグリゲート３００を調節するために用いられる機能ユニットがまとめられる。
【００２２】
第２のモジュールＣＯ内には，ハードウェアが制御装置１００のモジュールと通信可能な状態で，制御装置１００のハードウェアの独立したプログラミングを可能にする機能ユニットがまとめられる。さらに，第２のモジュールＣＯは，モジュールＡＳＷ，ＣＯ，ＤＥ，ＣＤ内の機能ユニットの機能の処理を時間的に調整する機能ユニットを有している。さらに，第２のモジュールＣＯは，モジュールＡＳＷおよび／または第３のモジュールＤＥと他の制御装置との通信を可能にする機能ユニットも有している。
【００２３】
第３のモジュールＤＥ内には，後述するセンサ／アクチュエータ構成の個々のセンサまたはアクチュエータの間で制御装置１００の残りのモジュールとの通信ができるように，センサ／アクチュエータ構成を制御装置１００に個別に適合させることを可能にする機能ユニットがまとめられる。
【００２４】
そして，第４のモジュールＣＤ内には，制御装置１００に対する複雑なインターフェイスを備えた複雑なセンサ／アクチュエータ構成を第１のモジュールによって直接駆動することを可能にする機能ユニットがまとめられる。この特殊なセンサ／アクチュエータ構成は，上述した特殊でないセンサ／アクチュエータ構成とは区別される。第１のモジュールとの通信が第２と第３のモジュールのみを介して行われる，固有でない構成とは異なり，特殊な構成においては，第１のモジュールとの通信は直接第４のモジュールを介して行われる。
【００２５】
モジュールＡＳＷ，ＣＯ，ＤＥ，ＣＤの間には，それぞれ，モジュールの相互の通信も個々のモジュールの交換も可能にする，モジュールインターフェイスＭ１，Ｍ３，Ｍ３，Ｍ４，Ｍ５およびＭ６が設けられている。
【００２６】
図２は，上述したモジュールＡＳＷ，ＣＯおよびＣＤの内部のコンポーネントを本発明に従ってグループ化することを示している。第１のモジュールＡＳＷは，ユーザや利用者の基本的な情報を得る機能を表している。異なるタイプの駆動アグリゲートを制御装置によって駆動させる，設計の適用に関して，第１のモジュールＡＳＷを車両コンポーネントＶＦと駆動アグリゲートコンポーネントＥＦに分割することが，有意義である。
【００２７】
車両コンポーネントＶＦは，好ましくは，所定のタイプの駆動アグリゲート３００にとって固有（特有）ではない機能ユニットを有している。その機能ユニットは，特に，冒頭で説明したような，機能ユニット駆動ＶＦ−１，車両コーディネータＶＦ−２，車両運動ＶＦ−３または走行状態量ＶＦ−４である。
【００２８】
それに対して駆動アグリゲートコンポーネントＥＦ内には，用いられるタイプの駆動アグリゲート３００に固有なすべての機能ユニットがまとめられる。このような機能ユニットは，好ましくは，図９を参照してすでに説明したような，機能ユニットエンジンコーディネータＥＦ−１，エンジントルク構造ＥＦ−２，ガスシステムＥＦ−３または噴射システムＥＦ−４である。そのとき，制御装置１００によって駆動すべき駆動アグリゲート３００が変化した場合に，もはや複雑な第１のＡＳＷモジュールを交換する必要はなく，好ましいことに，単に駆動アグリゲートコンポーネントＥＦのみが交換されれば十分である。
【００２９】
第１のモジュールの場合と同様に，第２のモジュールにおいて，例えば制御装置１００内で使用すべき他のプロセッサに関して，第２のモジュールをインフラ構造コンポーネントＩＳとハードウェアカプセルコンポーネントＨＷＥに分割することが，推奨される。インフラ構造コンポーネントＩＳ内には，好ましくは，基本的なサービスを提供し，または表し，他の機能ユニットにアクセスすることができるすべての機能ユニットがまとめられる。その機能ユニットは，上述同様に，好ましくは機能ユニットサービスライブラリーＩＳ−１，シーケンス制御ＩＳ−２，診断マネージャＩＳ−３および監視コンセプトＩＳ−４である。サービスは，インフラ構造コンポーネント内では中央箇所で準備される。従って，複数に分散することによって，不要なメモリスペースを要求する必要がない。
【００３０】
ハードウェアカプセルコンポーネントＨＷＥ内には，配置換えされたハードウェア１００ａが制御装置１００のモジュールＡＳＷ，ＣＯ，ＤＥまたはＣＤと通信できるように，制御装置１００のハードウェア１００ａの独立したプログラミングを可能にするすべての機能がまとめられる。すなわち，制御装置内で使用されているプロセッサを他のタイプのプロセッサと交換する場合に，ハードウェアカプセルコンポーネントＨＷＥのみを交換すればよく，もはや制御装置の第２のモジュール全体を交換する必要はない。
【００３１】
上述したインフラ構造コンポーネントとハードウェアカプセルコンポーネントの他に，第２のモジュールＣＯは，さらに，通信コンポーネントＣＯＭを有することができ，その中には，他の制御装置との通信を可能にする機能ユニットがまとめられている。
【００３２】
モジュールレベルのすでに上述したモジュールインターフェイスＭ１…Ｍ６の他に，個々のモジュール内部にコンポーネントレベルのコンポーネントインターフェイスも設けられている。これらコンポーネントインターフェイスＫ０…Ｋ３は，モジュール内部のコンポーネントの少なくとも個々のコンポーネント間におけるデータ交換を可能にする。すなわち，第１のモジュール内で車両コンポーネントＶＦと駆動アグリゲートコンポーネントＥＦの間にインターフェイスＫ０がある。第２のモジュールの内部には，インフラ構造コンポーネントＩＳと通信コンポーネントＣＯＭとの間にコンポーネントインターフェイスＫ１，インフラ構造コンポーネントＩＳとハードウェアカプセルコンポーネントＨＷＥの間に第２のインターフェイスＫ２，そしてハードウェアカプセルコンポーネントＨＷＥと通信コンポーネントＣＯＭとの間に第３のインターフェイスＫ３が設けられている。
【００３３】
図３には，車両コンポーネントＶＦおよび駆動アグリゲートコンポーネントに対する機能ユニットのすでに説明した対応づけと，両コンポーネント間のインターフェイスＫ０が示されている。さらに，図から明らかなように，コンポーネントの内部で機能ユニットは，機能ユニットインターフェイスＦｉ（ｉ＝１−９）を介して互いに通信することができる。モジュール内部で異なるコンポーネントに対応づけられている機能ユニット間の通信は，上述したコンポーネントインターフェイス，ここではＫ０を介して行われる。
【００３４】
図４は，第２のモジュールの内部におけるインフラ構造コンポーネントＩＳとハードウェアカプセルコンポーネントＨＷＥに対する機能ユニットのすでに説明した対応づけを示している。図３を参照してすでに行った，機能ユニットとコンポーネントとの間のインターフェイスについての説明は，ここでも同様に有効である。図３と４に示す，コンポーネント内部において機能ユニット間の機能ユニットインターフェイスを形成する代わりに，あるいはそれに加えて，これらのインターフェイスが，コンポーネントの内部の各機能ユニットへ直接接続されるように形成することもできる。その場合には例えば，機能ユニットサービスライブラリーＩＳ−１と機能ユニット診断マネージャＩＳ−３との間の通信において，機能ユニットシーケンス制御ＩＳ−２を介した通信を要せず，直接的な接続が提供される。
【００３５】
ＨＷＥの機能ユニットＨＷＥ−１…Ｎについては，これらの機能ユニットをそれぞれプロセッサレベル素子とハードウェア抽象レベル素子に分割することが効果的である。この分割は，プロセッサを意図的に交換する場合に，ハードウェアカプセルコンポーネント全体ではなく，プロセッサレベル素子のみを交換すればよく，もちろん，ハードウェアカプセルコンポーネントＨＷＥのすべての機能ユニットを交換する必要はない，という利点を提供する。その場合，プロセッサ以外の制御装置のハードウェアである，制御装置の周辺ハードウェアを意図的に交換する場合，上記同様，もはやハードウェアカプセルコンポーネントＨＷＥ全体を交換する必要はなく，ＨＷＥのすべての機能ユニットにおいてハードウェア抽象レベル素子の交換で十分である。
【００３６】
ハードウェアカプセルコンポーネントＨＷＥに対応づけられた１つの機能ユニットは，冒頭で説明した，機能ユニット信号編集ＨＷＥ−１である。機能ユニット信号編集ＨＷＥ−１に関して，プロセッサレベル素子ＨＷＥ−１−１が，使用されるプロセッサタイプに関する限りにおいて，信号編集を中継し，ハードウェア抽象レベル素子ＨＷＥ−１−２が，制御装置内で使用される周辺ハードウェアに関する限りにおいて，信号編集を中継する。
【００３７】
さらに，インターフェイスＥｋが，プロセッサレベル素子ＨＷＥ−１−１とハードウェア抽象レベル素子ＨＷＥ−１−２の互いに対する通信，および／または，それらの上位にあたる，ＨＷＥ内の機能ユニットＨＷＥ−１との通信のために，設けられている。
【００３８】
図５は，すでに説明した，第４のモジュールＣＤを複数の機能ユニットに効果的に分割することを示している。これら機能ユニットは，第４のモジュール上でコンプレックス機器ドライバＣＤ−ｉ（i＝１…Ｎ）とも称される。これらコンプレックス機器ドライバの各々は，それ自体好ましくは，機器ドライバ素子ＣＤ−ＧＴとハードウェアドライバ素子ＣＤ−ＨＷに分割される。素子ＣＤ−ＧＴは，インターフェイスＭ３を介して第１のモジュールＡＳＷに接続されている。このインターフェイスＭ３を介しては，例えば噴射量または回転数のような物理的な変量を表すソフトウェア信号が伝達される。機器ドライバ素子ＣＤ−ＧＴがこの種のソフトウェア信号を第１のモジュールＡＳＷから受信した場合，機器ドライバ素子は，この信号を，駆動すべきアクチュエータにとって固有ではあるが，制御装置ハードウェアにとってはまだ固有ではない，他のソフトウェア信号に変換する。逆の場合に，機器ドライバ素子ＣＤ−ＧＴがこの種の他のソフトウェアをハードウェアドライバ素子ＣＤ−ＨＷから受信した場合には，同素子はこの信号を，物理的な変量のみを表すが，最初にそれを発生したセンサにとってはもはや固有ではない，ソフトウェア信号に変換する。ハードウェアドライバ素子ＣＤ−ＨＷは，特殊なセンサ／アクチュエータ構成２００が使用される制御装置ハードウェア，特に使用されるプロセッサ１００ａ−１に直接結合される。機器ドライバ素子ＣＤ−ＧＴと付属の他のハードウェアドライバ素子ＣＤ−ＨＷとの間には，それぞれインターフェイスＥｉ（ｉ＝１…Ｎ）が設けられている。
【００３９】
コンプレックス機器ドライバの１つは，冒頭で説明した機能ユニットアグリゲート位置−マネージメントＥＰＭである。その機器ドライバ素子とそのハードウェアドライバ素子は，一義的な対応づけのために，参照符号ＣＤＥＰＭ−ＧＴとＣＤＥＰＭ−ＨＷとする。
【００４０】
図６は，モジュールインターフェイスＭ２とＭ４を例示している。矢印は，それぞれインターフェイスによって実現される，図示のモジュールまたはそのコンポーネントの間の従属関係を示している。その場合に１つのモジュールが他のモジュールに依存し，あるいは１つのコンポーネントが他のコンポーネントに依存しているという表現は，このモジュールが他のモジュールに，あるいはこのコンポーネントが他のコンポーネントにアクセスし，または，他のモジュールもしくは他のコンポーネントから依頼を受けて処理すべきデータを与えることを，意味している。従属関係を表す矢印は，必ずしも該当するデータフロー方向も示しているわけではない。これについては，後に図８を参照して説明する。図６から明らかなように，第３のモジュールＤＥと第１のモジュールＡＳＷの間には，相互的な関係が存在する。第３のモジュールから第１のモジュールへ向けられている矢印によって表される，第１のモジュールＡＳＷが第３のモジュールＤＥに依存していることは，第１のモジュールＡＳＷに対して第３のモジュールが例えばセンサ信号および／または，センサ信号の品質に関する情報を表す付属の品質信号を準備するように，第１のモジュールが指示したという事実に基づいている。
【００４１】
図６からさらに明らかなように，第４のモジュールインターフェイスＭ４は，インフラ構造コンポーネントおよびハードウェアカプセルコンポーネントの第３のモジュールＤＥに対する一方的な関係と，第３のモジュールＤＥに対する通信コンポーネントＣＯＭの相互的な関係を表している。上述した３つのコンポーネントすべてが，第２のモジュールＣＯに対応づけられている。インフラ構造コンポーネントとハードウェアカプセルコンポーネントの一方向の従属関係は，第３のモジュールＤＥが，これらのコンポーネントに対して，そこでデータを処理させるためにアクセスすることを意味している。第２のモジュールＣＯと第３のモジュールＤＥとの間のインターフェイスＭ４について上述したのと同様な関係が，第２のモジュールＣＯと第４のモジュールＣＤとの間のインターフェイスＭ６についても存在する。
【００４２】
図７は，同じモジュールの異なるコンポーネント内の２つの機能ユニット間におけるコンポーネントにまたがる通信の例を示している。さらに正確には，図７は，ハードウェアカプセルコンポーネントＨＷＥ内部の機能ユニット信号編集ＨＷＥ−１とインフラ構造コンポーネントＩＳの内部の機能ユニット診断マネージャＩＳ−３との間の通信を示している。ここでは，機能ユニット信号編集は，機能ユニット診断マネージャに依存している。これは例えば，機能ユニット信号編集ＨＷＥ−１が機能ユニットＩＳ−３へ信号を送信して処理を依頼することを意味するとしても良い。送信される信号は，例えば制御装置１００に対応づけられたハードウェア１００ａ内の故障を表す。その場合に信号の送信によって機能ユニット信号編集ＨＷＥ−１は，機能ユニット診断マネージャに，この信号を処理すること，すなわち例えば再送（デバウンス）することを依頼するので，この信号のエラーのない評価が可能になる。その場合，信号編集の他に，機能ユニット診断マネージャに例えばこの信号を格納するといった課題も当然与えられるので，その信号を後の時点で，例えば自動車修理工場内で，エラー診断のために読み出すことができる。
【００４３】
そして図８は，制御装置ソフトウェア１００ｂの内部における個々のモジュールの協働を，信号の推移の例を用いて説明している。この種の信号推移考察は，すでに上述した関係考察と比較して，特に，モジュール間の，個々のインターフェイスの機能を説明している。２つの考察方法は，互いに矛盾するものではなく，ただ，インターフェイスの機能を異なる方法で説明するものである。
【００４４】
具体的には，図８に，制御装置１００を有する内燃機関３００を組み込んだ車両の運転者が，アクセルペダルを操作した場合に得られる信号の推移が示されている。アクセルペダルあるいはそれに固定されている位置検出器は，図８において，センサ／アクチュエータ構成２００のセンサとして参照符号２００ａで表されている。アクセルペダルの位置の変化を表す信号Ｓ１は，アクセルペダルからまず制御装置１００のハードウェア１００ａへ入力される。制御装置ハードウェア１００ａ内において実際の電気的なセンサ信号がソフトウェア信号に変換される。そのソフトウェア信号は，最初はまだ制御装置固有である。このソフトウェア信号Ｓ２は，その後制御装置ハードウェア１００ａを出て，第２のモジュールＣＯ，もっと正確に言うとそのハードウェアカプセルコンポーネントＨＷＥ内へ供給される。そこでソフトウェア信号は，その中にまだ含まれている制御装置ハードウェア１００ａの影響をその信号から取り除かれるように編集される。その場合にハードウェアカプセルコンポーネントＨＷＥの出力には，影響が取り除かれたソフトウェア信号が出力され，それは特に，もはやプロセッサ特徴を有していない。しかしそれは相変わらず，例えば３Ｖの振幅を有した元の電気信号の特徴，すなわち変化されたアクセルペダル位置を表している。この影響が取り除かれた信号Ｓ３は，その後モジュールインターフェイスＭ４を介して第３のモジュールＤＥへ供給される。影響が取り除かれた信号Ｓ３は，第３のモジュールＤＥ内で，その周辺に対するセンサのインターフェイスに関する物理的なレベルに変換されるように編集される。例えばこれは，３Ｖの振幅の形式の信号によって表された第３モジュールへの入力信号Ｓ３を，アクセルペダル位置の実際量，例えばアクセルペダルで回転可能な回転角の７５％という形式に変化させることによって，第３のモジュールＤＥから物理的な信号Ｓ４が出力されることを意味するとしても良い。物理的な信号Ｓ４は，第１のモジュールＡＳＷと第２のモジュールＤＥの間のインターフェイスＭ２の一部である。この信号は，第３のモジュールから直接第１のモジュールＡＳＷへ，もっと正確に言うとその車両コンポーネントＶＦへ達する。車両コンポーネントＶＦは，物理的な入力信号Ｓ４を，内燃機関３００に対するトルク要請と解釈する。車両コンポーネントは，第３のモジュールからのこのトルク要請と，場合によっては，存在する他のモジュール，コンポーネントまたは機能ユニットから内燃機関へなされるトルク要請とを合わせて調整し，最終的な結果として内燃機関にもたらされる目標トルクを信号Ｓ５の形式で出力する。
【００４５】
その後，駆動アグリゲートコンポーネントＥＦは，受信した目標トルクを内燃機関のタイプに依存する物理的な変量に変換する。内燃機関３００が，例えばディーゼル機関である場合には，アグリゲートコンポーネントＥＦは，必要とする目標トルクを調節するために必要な物理的目標噴射圧を表す第１の操作量信号Ｓ６と，予め定められた目標トルクを調節するために必要な，物理レベルの目標燃料量を表す第２の操作量信号Ｓ１０を形成する。それぞれ生成された操作量が通常のアクチュエータ用に設けられているか，あるいは複雑なインターフェイスを有する特殊なアクチュエータのために設けられているか，に従って，駆動アグリゲートコンポーネントＥＦは操作量を第３のモジュールＤＥあるいは第４のモジュールＣＤへ出力する。これまで説明してきた例においては，第１の操作量Ｓ６は，圧力制御弁２００ｂ２を駆動するために設けられており，その圧力制御弁は複雑なインターフェイスのない通常のアクチュエータである。従って駆動アグリゲートコンポーネントＥＦは，第１の操作量信号Ｓ６をインターフェイスＭ２を介して第３のモジュールＤＥへ出力する。第３のモジュールは，入力された物理的な操作量Ｓ６（ソフトウェア信号）を，制御装置ハードウェア１００ａにとって固有ではない電気信号Ｓ７の形式の物理的な目標圧力を表すソフトウェア信号に変換する。この信号Ｓ７は，モジュールインターフェイスＭ４を介して第２のモジュールＣＯへ出力され，そこでその信号はそのハードウェアカプセルコンポーネントＨＷＥによって，制御装置ハードウェア１００ａにとって固有の電気信号を表すソフトウェア信号に変換される。この変換は，例えば，制御装置ハードウェアの要請に応じた量子化として取り扱うことができる。ハードウェアカプセルコンポーネントＨＷＥによって生成されて出力される信号Ｓ８は，制御装置ハードウェア１００ａへ供給され，その制御装置ハードウェア１００ａが，この信号を，アクチュエータとしての圧力制御弁２００ｂ２を駆動するための実の電気信号に変換する。
【００４６】
第１の操作量信号Ｓ６の処理と並行して，上述した例においては，第２の操作量信号Ｓ１０が，モジュールインターフェイスＭ３を介して第４のモジュールへ伝達された後に，第４のモジュールＣＤによって処理される。第４のモジュールは，要請された目標トルクの実現に必要な目標燃料量を物理的な形式で表す信号Ｓ１０を，制御装置ハードウェア１００ａにおいて固有の信号を表すソフトウェア信号に変換する。その限りにおいて，第４のモジュールＣＤは，一度に，第３のモジュール，および，燃料量を調節するための噴射弁２００ｂ１を示す複雑なインターフェイスを備えた特殊なアクチュエータのためのハードウェアカプセルコンポーネントの機能を引き継ぐ。上述した，第４のモジュールＣＤから出力されるソフトウェア信号Ｓ１１は，その後，上記同様に制御装置ハードウェア１００ａへ供給され，それによってこの制御装置ハードウェアが受信したソフトウェア信号が，アクチュエータとしての噴射弁２００ｂ１を駆動するための実際の電気信号に変換される。このようにして行われる，圧力制御弁２００ｂ２と噴射弁２００ｂ１の駆動は，一緒になって，変化したアクセルペダル位置による運転者の意図もしくはその運転者意図を表す目標トルクに関する内燃機関３００のトルクの変化をもたらす。内燃機関３００がディーゼル機関ではなく，ガソリン機関である場合には，駆動アグリゲートコンポーネントＥＦによって３つの操作量信号が形成される。このとき，第３のモジュールＤＥへ出力される第１の操作信号Ｓ６は，調節すべき空気質量のための目標値を表し，第４のモジュールへ出力される第２の操作信号Ｓ１０は，目標トルクを実現するために必要な目標燃料量を表す。さらに，第３の操作量信号Ｓ１３が，上記同様に，駆動アグリゲートコンポーネントＥＦから第４のモジュールＣＤへ出力され，その場合に操作量信号Ｓ１３は，内燃機関の点火プラグのための点火時点を定める。
【００４７】
第１の操作量信号Ｓ６は，信号Ｓ７，Ｓ８およびＳ９へ変換した後に絞り弁を駆動するために用いられ，第２の操作量信号Ｓ１０は，信号Ｓ１１とＳ１２へ変換した後に，噴射弁を駆動するために用いられ，第３の操作量信号Ｓ１３は，信号Ｓ１４とＳ１５へ変換した後に，点火プラグ２００ｂ３を駆動するために用いられる。図８においてモジュールまたはコンポーネントの内部に記入された破線は，単に入力信号と出力信号の対応づけを表している。それらは，モジュールまたはコンポーネント内部における入力信号の処理を明確に排除（否定）するものではない。
【００４８】
機能ユニット，コンポーネントまたはモジュールは，好ましくはコンピュータプログラムとして実現される。その場合，コンピュータプログラムを，場合によっては，駆動アグリゲートを制御するための他のコンピュータプログラムと共に，コンピュータで読み取り可能なデータ記憶媒体上に格納することが可能である。そのデータ記憶媒体は，ディスケット，コンパクトディスク，いわゆるフラッシュメモリなどとすることができる。その場合にデータ記憶媒体上に格納されているソフトウェアは，製品として顧客に販売することができる。さらに，ソフトウェアで実現する場合においては，コンピュータプログラムを，ここでも場合によっては他のコンピュータプログラムと共に，データ記憶媒体を用いなくても，電子的な通信ネットワークを介して製品として顧客へ伝達し，販売することが可能である。通信ネットワークは，例えばインターネットとすることができる。
【００４９】
これまで説明してきた実施形態の特殊な拡張では，モジュール，特にＤＥとＣＯの入力および出力信号の構成と対応づけならびにその説明が具体的に示唆される。その場合には，モジュール，特にＣＯとＤＥ間の信号の対応づけを可能にする，中間モジュールもしくは中間層ＳＺＳが導入される。それが，図１０に示されている。図には，すでに説明したようなモジュールＣＯ，ＣＤ，ＤＥ，ＡＳＷが示されている。モジュールＣＯとＤＥの間には，構成データを構造化するための具体的なインターフェイス，いわゆる構成インターフェイスＫＳＳが示されている。これは，主要な部分として，信号を対応づけるためのルーティングモジュールである信号対応付け層ＳＺＳを有している。このＳＺＳは，ハードウェア近位の層，即ちモジュールＣＯに対応づけられている。さらに，要請モジュールまたは要請層ＡＳが，モジュールＤＥに対応づけられている。このＳＺＳまたはＫＳＳ全体によって，普遍的かつフレキシブルな信号対応付けが行われるので，モジュールＣＯとモジュールＤＥは，互いに交わされる入出力信号またはその具体的な配置に拘わらず構想を練ることができる。というのは，具体的な信号対応づけは中間層，モジュールＳＺＳ内で行われるからである。
【００５０】
選択された表示において，モジュールの構成は，好ましくは構成パラメータの記述ＸＭＬを介して行われ，それは構成ジェネレータによって，対応する＊．ｃ−と＊．ｈ−データファイルに変換される。このドキュメントは，ＸＭＬベースのテキストデータファイルを介してソフトウェアパケットデジタルインプット／アウトプット（ＤＩＯ）の構成を記述する。このＸＭＬデータファイル内で，特に信号クラスＤＩＯの特性が定められる。ＤＩＯ特性の記述は，種々の作業レベルで実施される。一方，ＤＩＯ信号は，パラメータ方向，初期化値および適用可能性を有する，プロジェクトに依存しないデバイスエンキャプスレーションによって要請され（ＤＩＯ＿ＳＩＧＮＡＬ＿ＲＥＱＵＥＳＴ），他方ではこれらの信号はプロジェクト固有の適用に反映されなければならず，すなわち信号は対応するハードウェアへルートが必要である（ＤＩＯ＿ＳＩＧＮＡＬ＿ＲＯＵＴＩＮＧ）。要請されるハードウェアピン（ＰＩＮ）は，同じように構成されなければならない（ＤＩＯ＿ＳＩＧＮＡＬ＿ＩＭＰＬＥＭＥＮＴ）。
【００５１】
＜様々な構成レベルの説明＞
デジタルの入力および出力信号を説明する場合に，デバイスエンキャプスレーション（ＤＥ），ハードウェアアブストラクションレイヤー（ＨＡＬ＝ＳＺＳ）およびハードウェア構成（モジュールＣＯ）が区別される。しかし，この配置は，他の層の間でも行われ，または，残りのモジュール間でも使用可能である。選択的に例えば，ＫＳＳ３としてのＡＳＷとＣＯ，またはＫＳＳ４としてのＡＳＷとＤＥ，あるいはＫＳＳ５としてのＡＳＷとＣＤ，およびＫＳＳ２としてのＣＤとＤＥの間である。このとき，ＫＳＳの場合と同様に常に，ハードウェア構成として，ここでは，ＣＯのような出力モジュールと，要請モジュールもしくは要請層ＡＳを有する，ＫＳＳにおけるＤＥのような目標モジュールと，対応づけ層もしくはルーティングモジュールＳＺＳと，が含まれている。これらの基本構造は，残りの構成インターフェイスＫＳＳ２からＫＳＳ５にも転用できる。以下においては，ＫＳＳ，従ってＣＯとＤＥのみを挙げて記述し，それによって残りのインターフェイスＫＳＳ２−ＫＳＳ５も同様に説明でき，適用可能と見なすことができる。
【００５２】
ＤＥのコンポーネントドライバのための重要な構成パラメータは，抽象的に，かつプロジェクトに依存せずに示すことができる。デジタルの入力および出力信号においては，このレベルで例えば信号名，方向および初期化値が重要である。その場合にコンポーネントドライバの視点からは，後にどのハードウェア上でコンポーネントドライバが遂行されるか，は（フレーム条件の遵守を前提として）何ら役に立たない。
【００５３】
ＨＡＬの構成は，該当するハードウェアへの信号名のルーティングを有している。この層内で，信号に，属するハードウェアピンネームが割り当てられる。
【００５４】
ハードウェア固有の構成調節は，最も下のレベルで行われる。このレベルの構成パラメータは，該当するモジュールもしくは信号クラスに関係し，もはやプロジェクトおよびハードウェアに依存せず考えることができる。信号の対応づけは，このモジュール上で所望のポートもしくはピンによるハードウェアモジュールの記載（例えばＡＤＣ，ＧＰＩＯまたはＣＹ３１０，ＣＹ１００など）を介して行われる。ＡＤＣモジュールにおいては，さらに，ハイまたはローを介して決定するしきい値電圧を記載しなければならない。
【００５５】
レジスタ値の調節は，ポートハードウェア層（レイヤー）の構成を介して行われる。このレベルに，モジュールをまたぐ要請が集まる。例えば，パラレルインターフェイスに対して，種々のモジュールないし信号クラス（ＧＰＩＯ，ＧＰＴＡ，ＳＳＣ，ＣＡＮなど）による要請が存在する。この理由からハードウェア調節は，信号クラス内でモジュール固有に行うことはできない（構成プロセスも参照）。
【００５６】
従って，上記ＤＩＯ構成は，様々な構成レベルで行われる：
−デバイスエンキャプスレーションＤＥ：信号の要請
−ハードウェアエンキャプスレーション／ＨＡＬ＝ＳＺＳ：信号のルーティング
−ハードウェア構成ＣＯ：ハードウェア層の構成
【００５７】
（構成の３つの層（層／データファイル／内容））
ＤＥ／paketname．xml／信号名，方向（イン，アウト），適用可能性ないしアクセス種類の調節（マクロまたは関数）
ＨＡＬ（ルーティング）／project.xml／信号名，ハードウェアモジュール，ポート，ピン，［しきい値（ＡＤＣ）］
ハードウェア構成／hardware.xml／ハードウェア特性，レジスタ調節
【００５８】
構成を種々のレベルに分割することは，デジタルの入出力信号またはＤＩＯモジュールの構成にのみ限定されず，他のモジュール（ＡＤＣ，ＰＷＭ）における構成も，場合によっては多少相違する場合も含めて，前者の分類に従って行われる。
【００５９】
ＸＭＬ構成データファイルの名称は，原則的に自由に選択可能である。ＤＥの内部には，確かにパケット指向の多数の構成データファイルが生じる。ＨＡＬレベルで，信号ルーティングは中央のＸＭＬデータファイルに分割するか，あるいはまた種々の構成データファイルに分割することができる。その場合にさらに，どの分割がプロジェクト固有の構成の構造化に最も適しているかを，はっきりさせなければならない。同じことが，ハードウェアの調節またはレジスタ構成についても言える。
【００６０】
（信号の要請）
ＤＩＯのためのＸＭＬ記述（パケット層−ＤＥ）
<CONF>
<DIO>
<DIO_SIGNAL_REQUEST>
<DESC>Break signal</DESC>
<DIO_SIGNAL_NAME>E_A_BRK</DIO_SIGNAL_NAME>
<DIO_DIR>IN</DIO_DIR>
<DIO_CALIBRATION>YES</DIO_CALIBRATION>
<DIO_INIT>HIGH</DIO_INIT>
</DIO_SIGNAL_REQUEST>
</DIO>
</CONF>
【００６１】
このレベル上で，ＤＥからパケットによって信号が要請される。各パケットは，１つまたは複数のＸＭＬデータファイルに任意のデータファイル名を与え，Ｃｏｒｅ／Ｈｗｅ／Ｄｉｏモジュールのデジタルの入力および出力信号を要請しまたは予約することができる。そのためにはＤＩＯ（パケット層−ＤＥ）のためのＸＭＬ記述からパケットシンタックスをこのＸＭＬデータファイルへコピーして適合させなければならない。
【００６２】
上の例においては，パケット”ＤＩＯ”内で”Ｅ＿Ａ＿ＢＲＫ”の名称を有する信号が使用されることが確認され，その信号は所定の方向（ここでは入力のための”ＩＮ”）を有しかつ適用可能であり（適用可能ということは，ランタイムのための信号ルーティングが信号テーブルを用いて行われ，従って駆動の間変更できることを意味している。信号データがコンパイルタイムのためだけに定められる場合には，ランタイムのために信号を迂回させることはもはやできない），あるいは適用可能ではない（ここでは”ＹＥＳ”は適用可能）。種々の信号の構成は，ＸＭＬデータファイル内で任意の回数繰り返すことができる。
【００６３】
（注：）
タグＤＩＯ＿ＣＡＬＩＢＲＡＴＩＯＮ＿とＤＩＯ＿ＩＮＩＴは，選択的なタグである。これらは，すでにＤＥ層からアクセスまたは初期化に対する要請が前提としてある場合にのみ定められる。これらのタグは構成に対する要求である。ＨＷレベル上で異なる調整が行われる場合には，ＤＥ層からの要請は上書きされて，レポートデータファイル内にまとめて記録される（データファイルの引出しも参照tmp/include_tmp/dio_report.txt）。
【００６４】
（信号のルーティング）
ＤＩＯのためのＸＭＬ記述（プロジェクト層．ＨＡＬ）。
<CONF>
<DIO>
<DIO_SIGNAL_ROUTING>
<DESC>Break signal</DESC>
<DIO_SOURCE>E_A_BRK</DIO_SOURCE>
<DIO_TARGET>GPIO_P8_P0_IN</DIO_TARGET>
</DIO_SIGNAL_ROUTING>
</DIO>
</CONF>
【００６５】
このレベル上でプロジェクトによって信号ルーティングが実施される。ソフトウェア信号名が，いわばハードウェアピンネームに割り当てられる。このハードウェアピンネームは，ハードウェア層内に構成される，所望のハードウェアリソースから得られる（ハードウェア層の構成を参照）。
【００６６】
ＤＩＯ（プロジェクト層．ＨＡＬ）のためのＸＭＬ記述に基づく例において，記述（ＤＥＳＣ）”Ｂｒｅａｋｓｉｇｎａｌ”によってパケット”ＤＩＯ”内で名称”Ｅ＿Ａ＿ＢＲＫ”を有する信号が使用されて，所定のハードウェアピンネーム”ＧＰＩＯ＿Ｐ８＿Ｐ０＿ＩＮ”（ポート”８”，ピン”０”，方向”ＩＮ”）に対応づけられることが，定められる（”ＧＰＩＯ”はパラレルインターフェイスへのアクセスを代表する）。種々の信号の構成は，ＸＭＬデータファイル内で任意の回数繰り返すことができる。
【００６７】
（ハードウェア層の構成）
ＤＩＯのためのＸＭＬ記述（ハードウエア層）
<CONF>
<DIO>
<DIO_SIGNAL_IMPLEMENT>
<DESC>hardware resource for
break signal</DESC>
<DIO_MODULE>GPIO</DIO_MODULE>
<DIO_PORT>8</DIO_PORT>
<DIO_PIN>0</DIO_PIN>
<DIO_DIR>IN</DIO_DIR>
<DIO_CALIBRATION>YES</DIO_CALIBRATION>
<DIO_INIT>HIGH</DIO_INIT>
</DIO_SIGNAL_IMPLEMENT>
</DIO>
</CONF>
【００６８】
ＴＣ１７７５／ＴＣ１７９６のハードウェア特性は，機能的な調節から分離されて，別の構成層（ＨＷレイヤー）内で定められる。各プロジェクトは，１つまたは複数のＸＭＬデータファイルに任意のデータ名をつけて，モジュールとそのポートおよびピン（出力段とピン）に所定の特性を対応づけることができる。これらのモジュールは，デジタル信号の読込みと出力のために層内で機能的でなければならない。そのためにＤＩＯ（ハードウェア層）のためのＸＭＬ記述から，シンタックスがこのＸＭＬデータファイルへコピーされて，適応されなければならない。
【００６９】
上述の例において，記述（ＤＥＳＣ）”ＧＰＩＯ＿Ｐ８＿Ｐ０＿ＩＮ”によって，パケット”ＤＩＯ”内で名称”ＧＰＩＯ”を有するモジュールが使用されることが定められる（”ＧＰＩＯ”は，パラレルインターフェイスを代表する）。このモジュールによってリソース（ポート”８”，ピン”０”）が要請されて，（ここでこれが入力として意味をなす限りにおいて）アプリケーション識別子”ＹＥＳ”と初期化値”ＨＩＧＨ”が割り当てられる。種々の信号の構成を，ＸＭＬデータファイル内で任意の回数繰り返すことができる。
【００７０】
（種族に関するハードウェアピンネーム）
ハードウェアピンネームは，純粋に種別に関する名称であって，ハードウェアリソースに一義的に対応づけられ，以下のパターンに従ってまとめられる。
＜モジュール名＞＿Ｐ＜ポート番号＞＿Ｐ＜ピン番号＞＿＜方向＞
例えば，GPIO_P8_P0_IN
【００７１】
ハードウェアピンネームは，コンフィグレーションランに従ってＤＩＯレポートデータファイルから取り出される（以下の種別に関するハードウェアピン名を参照）。
【００７２】
（データファイルtmp/include_tmp/dio_report.txtの抜粋）
DIO Report
Signal Map -
Digital Input/Output Signals
Signal name:
OUTPUT
HW Signal:
GPIO_P9_P0_OUT
Module: GPIO
Port: 9
Pin: 0
Calibration: YES
Signal name:
INPUT
HW Signal:
GPIO_P9_P4_IN
Module: GPIO
Port: 9
Pin: 4
Calibration: YES
Signal name:
INPUT2
HW Signal:
GPIO_P9_P8_IN
Module: GPIO
Port: 9
Pin: 8
Calibration: YES
【００７３】
（注：）
これらＸＭＬエレメント<DIO_CALIBRATION>と<DIO_INIT>がそれぞれ２つの異なる層内で行われることが明らかになる。２つのＸＭＬエレメントは選択的であり，すなわちこれらが明確に記載されていない場合には，以下のデフォルト調節に基づく：
<DIO_CALIBRATION>NO</DIO_CALIBRATION>
<DIO_INIT>LOW</DIO_INIT>
【００７４】
これらのＸＭＬエレメントがＤＥ層（信号の要請）内にも，ハードウェア層の構成においても存在する場合には，プロジェクトレベル上ではハードウェア層内の調節の方が優先順位は高い。その場合に，プロジェクトレベルが固有の調節を行い，かつＤＥ層に対しても押し通すことができると仮定される。万一の重複は，一緒に記録されて，後からコンフィグレーションランに従って理解することができる。
【００７５】
（ＸＭＬ構成データファイルの記録）
信号の要請に基づく構成の実施と信号のルーティング後に，記憶されているＸＭＬデータファイルがそれぞれのメークファイル内にエレメントＣＯＮＦの元で記入されなければならない，図５：記入されたＸＭＬ構成データファイルによるメークファイルを参照。
【００７６】
（記入されたＸＭＬ構成データファイルによるメークファイル）
#-----------------------------------------------------------------------------
# Module
definition
#-----------------------------------------------------------------------------
NAME                  
:= dio
INTERFACE             
:= dio.h
CONF                  
:= dio_request.xml dio_routing.xml dio_implement.xml
CSOURCES              
:= dio.c gpio.c
ASMSOURCES            
: =
IMPLEMENTATION        
:=
DATA                  
:=
SUBDIRS               
:= diocfg
【００７７】
（構成データの入力）
構成データの入力は，ＸＭＬブラウザ（例えばＸＭｅｔａｌ）を介して行われる。ミニプロジェクトの構成のためのドキュメントタイプ定義（ＤＴＤ）を用いて，ＸＭＬ構造が設定される。ミニプロジェクトの構成のためのＤＴＤは，ミニプロジェクト内のedc_hwevob上で/script/xml/medc17_conf.dtdの元にある。このＤＴＤは，コアパケット（モジュール）の開発者によって，すでに用意されている構成可能なデータに従って逐次拡張される。ＸＭＬ構成データファイルは，このＤＴＤを介して蓋然化されなければならない。
【００７８】
（構成プロセス）
種々の構成レベルへ分割することによって，他の層の構成方法に関する詳細な知識なしで，様々なレベル上で調節を行うことが可能である。その場合に構成すべき層にとっては実際に重要でもある構成パラメータのみを記載すれば済む。
【００７９】
該当する層モデルが，図１１に示されている。
【００８０】
デジタル入力および出力信号の記述を用いて，このプロセスがわかりやすく説明される。一番上の層（ＤＥ）内では，信号クラスＤＩＯに対する信号要請がなされる。方向，初期化値およびパラメータ適用可能性の他に，信号名があって，その信号名を介してＤＥからの要請がＨＡＬ内のルーティングと結合される。ＨＡＬ内では，信号名をそれに応じたリソースに対応づけることができる。ＨＡＬ内の調節を有するマッピングは，信号名またはピンのハードウェアピンネームを介して行われる。ハードウェア層内には，モジュール名の他に，該当するポートないしピンも記載されなければならない。ＰＯＲＴハードウェアのための特性，例えばレジスタ調節は，別途，ＰＯＲＴ構成を介して行われる。個々の層の構成は，通常種々のＸＭＬデータファイルへ分配される。構成ジェネレータは，構成されたデータを検査し，かつこれを蓋然化する課題を有している。
【００８１】
（構成ジェネレータ）
ミニプロジェクト内で”make”または”make xml2conf”コマンドを呼び出した後に，記録されているＸＭＬ構成データファイルを用いて，ログオンされた構成データファイルのためのデータリストが生成される。それに基づいて，構成のための中央のＸＭＬパーサー（ehemals core_parse.pl）がすべての構成データファイルもしくはデータを集める。パーシングプロセスに続いて，独立した構成ジェネレータが始動されて，該当する＊．ｃ−ないし＊．ｈ−構成データファイルが生成される。
【００８２】
構成ジェネレータは，付加的にデータ一貫性をテストして，ユーザデータを蓋然化する。”メイクラン”が成功裏に終了した後に，制御装置コードで構成された信号が使用される。
【図面の簡単な説明】
【００８３】
【図１】制御装置に関する，本発明に基づくモジュールアーキテクチャを示している。
【図２】モジュールを本発明に基づいてコンポーネントに分割することを示している。
【図３】機能ユニットを本発明に基づいて車両コンポーネントと駆動アグリゲートコンポーネントに対応づけることを示している。
【図４】機能ユニットを本発明に基づいてインフラ構造コンポーネントとハードウェアカプセルコンポーネントに対応づけることを示している。
【図５】機器ドライバ素子のための機能ユニットを示している。
【図６】モジュール間のインターフェイスを示している。
【図７】様々なコンポーネント内の２つの機能ユニット間のインターフェイスを示している。
【図８】モジュール間のデータフローの例を示している。
【図９】従来技術に基づく制御装置の構造を示している。
【図１０】本発明に基づくインターフェイスアーキテクチャをモジュラーアーキテクチャに埋め込むことを示している。
【図１１】選択されたインターフェイスのレイヤー表示を示している。
【図１】
2006518436.tif 000003
【図２】
2006518436.tif 000004
【図３】
2006518436.tif 000005
【図４】
2006518436.tif 000006
【図５】
2006518436.tif 000007
【図６】
2006518436.tif 000008
【図７】
2006518436.tif 000009
【図８】
2006518436.tif 000010
【図９】
2006518436.tif 000011
【図１０】
2006518436.tif 000012
【図１１】
2006518436.tif 000013
【国際調査報告】
2006518436.tif 000014
2006518436.tif 000015
2006518436.tif 000016
2006518436.tif 000017
2006518436.tif 000018
2006518436.tif 000019
2006518436.tif 000020